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ABSTRACT 


In  the  early  stage  of  the  Weapons  Acquisition  Process  (Concept  Exploration  and 
Concept  Demonstration/Validation  Phases)  no  exact  and  reliable  data  are  available 
about  expected  Mean  Times  Between  Failures  (MTBF)  and  Mean  Times  to  Repair 
(MTTR)  for  both  the  components  of  a  new  system  or  the  new  system  itself.  Neverthe¬ 
less,  appropriate  decisions  have  to  be  made  about  the  number  of  maintenance  facilities 
at  certain  military  command  levels,  about  the  needed  quantity  of  (military  and/or  civil¬ 
ian)  maintenance  personnel,  and  about  adequate  spare  stock  levels  at  the  appropriate 
locations. 

Wrong  planning  in  this  early  stage  can  cause  a  degradation  of  the  new  system's  fu¬ 
ture  availability.  This  is  problematic  especially  with  electronic  equipment,  because 
maintenance  personnel  have  to  be  highly  specialized,  and  can  not  be  replaced  and  re¬ 
trained  as  easily  as  support  personnel  for  trucks  or  tanks. 

A  decision  aid  for  the  early  stages  of  the  acquisition  process  is  needed  that  offers 
insight  into  the  behavior  of  a  multi-indenture  level  electronic  system  within  a  three  ech¬ 
elon  maintenance  system,  develops  alternatives  for  upcoming  decisions,  and  finally  pro¬ 
vides  information  about  sensitive  factors  and  their  possible  tradeoffs,  essentially  used  in 
budgetary  discussions. 

The  purpose  of  this  thesis  is  the  exact  definition  of  all  relevant  factors  pertaining  to 
the  necessary  decisions,  the  review  of  existing  models  and  tools  and  their  review  for  ap¬ 
plicability.  Because  the  modification  of  existing  programs  can  not  solve  the  whole  scope 
of  the  problem  due  to  the  use  of  early  generation  computer  languages,  and  due  to  the 
necessarily  new  and  different  approach  to  the  topic,  a  new  simulation  program  has  to 
be  developed.  Using  object  oriented  simulation  language  MODSIM-II,  first  steps  to¬ 
wards  this  program  are  made,  but  remain  to  be  improved  and  completed  in  further  re¬ 
search  work. 


THESIS  DISCLAIMER 


The  reader  is  cautioned  that  the  computer  program  developed  in  this  research 
(MODSIM  Definition  and  Implementation  Modules)  have  not  been  exercised  within  a 
complete  program.  While  every  effort  has  been  made,  within  the  time  available,  to  en¬ 
sure  that  the  modules  are  free  of  logic  errors,  they  are  incomplete  and  can  not  be  con¬ 
sidered  validated.  Any  application  of  these  modules  in  a  MODSIM-program  without 
additional  verification  is  at  the  risk  of  the  user. 
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I.  INTRODUCTION  AND  PROBLEM  STATEMENT 


A.  LOGISTIC  SUPPORT  IN  THE  WEAPONS  ACQUISITION  PROCESS 

In  the  Weapon  Acquisition  Process,  both  within  the  U.S.  Armed  Forces  and  within 
the  Federal  Armed  Forces  Germany,  the  planning  for  providing  sufficient  and  efficient 
logistic  support  for  a  new  weapon  system  begins  in  the  early  stage,  in  the  Concept  Ex¬ 
ploration  Phase  and  the  Concept  Demonstration/Validation  Phase.  Quantity  and  quality 
of  maintenance  personnel,  maintenance  facilities,  spare  and  exchange  parts,  storage  fa¬ 
cilities,  tools,  manuals  and  training  have  to  be  determined  as  early  as  possible,  because 
the  lead  time  from  planning  to  acceptance  by  budgetary  commissions,  from  contracting 
parts  and  tools  to  actual  delivery,  and  from  hiring  personnel  until  their  final  ability  to 
repair  defective  equipment  is  nearly  as  long  as  the  actual  development  time  of  the  oper¬ 
ational  weapon  system  itself.  Using  the  concept  of  Integrated  Logistic  Support  (1LS 
[Ref.  1]),  this  problem  is  addressed  in  the  U.S. Army.  Nevertheless,  it  is  not  uncommon 
that  military  equipment  is  deployed  to  the  active  forces  without  sufficient  logistic  sup¬ 
port.  One  reason  is  based  on  the  fact  that  reliable  data  for  computing  necessary  and 
adequate  quantities  for  logistic  support  facilities  are  not  available  at  that  point  of  time 
they  are  needed. 

B.  SPECIAL  SITUATION  WITH  ELECTRONIC  MATERIEL 

Although  the  personnel  training  problem  with  conventional  equipment  (i.e.  equip¬ 
ment  based  on  mechanical,  electrical  or  weapons  engineering)  can  be  managed  by  reas¬ 
signing  existing  manpower  to  a  new  system  after  some  time  for  training,  this  problem  is 
more  crucial  for  electronic  materiel.  Complex  and  expensive  equipment  needs  thoroughly 
trained  and  highly  specified  personnel.  So  it  is  essential  to  avoid  delays  in  the  planning 
process,  caused  by  waiting  for  the  availability  of  data.  The  approach  developed  in  this 
thesis  concentrates  on  electronic  equipment. 

C.  PRELIMINARY  DECISIONS  BASED  ON  EXPERIENCE 

For  computing  the  number  of  maintenance  personnel  for  any  new  weapon  system  within 
a  given  military  maintenance  structure,  two  equipment  specific  data  are  essential: 

•  Mean  Time  Between  Failures  (MTBF) 

•  Mean  Time  To  Repair  (MTTR) 
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But  at  that  crucial  point  of  time  in  the  Weapons  Acquisition  Process,  at  which  numbers 
are  needed  to  get  started  in  time,  no  data  are  available  about  MTBF  and  MTTR  for  the 
components  of  a  new  system.  Even  the  system  itself  will  not  be  defined  in  any  precise 
form.  There  will  be  functional  units  with  defined  abilities,  there  will  be  components  with 
a  known  technology,  there  will  be  first  details  of  a  redundancy  concept. 

But  already  in  the  first  Acquisition  Decision  Memorandum  (ADM)  at  the  end  of  the 
Concept  Exploration  Phase,  numbers  for  quantities  are  entered.  Based  on  the  knowledge 
of  experienced  personnel,  these  numbers  are  not  necessarily  wrong.  In  fact,  these  initial 
numbers  often  turn  out  to  be  pretty  close  to  reality.  But  there  is  an  inherent  danger  of 
offering  data  that  can  not  be  justified.  In  times  of  economic  constraints  requests  based 
on  intuition  generally  are  not  accepted  by  budgeteers.  So  the  initial  numbers  are  adjusted 
to  budget  shortages  without  having  any  clue  about  the  sometimes  fatal  consequences  for 
the  logistic  support  system,  just  because  these  initial  numbers  can  not  be  backed  by  any 
kind  of  analysis. 

D.  THESIS  OVERVIEW 

Operations  Research  methods  seem  to  be  an  appropriate  way  to  resolve  this  situ¬ 
ation.  Formulating  the  given  problem  as  a  stochastic  model  and  applying  adequate  es¬ 
timation  and  calculation  methods  should  offer  numbers,  which  can  be  analyzed  for 
sensitivity  about  changes  of  all  kind,  and  can  not  be  rejected  solely  due  their  intuitional 
origin. 

In  proceeding  towards  this  goal,  the  following  steps  are  performed  in  this  thesis: 

•  In  Chapter  II,  the  overall  problem  is  described.  This  includes  a  presentation  of  the 
military  environment  with  emphasis  on  the  support  of  future  electronic  weapon 
systems.  Figures  1  and  2  illustrate  both  the  design  structure  of  a  future  electronic 
system  and  the  command  structure  of  its  area  of  deployment,  the  Federal  Armed 
Forces  Germany.  Figures  3  and  4  visualize  those  places  in  the  military  environ¬ 
ment,  where  both  structures  meet  -  the  different  kinds  of  military  maintenance  fa¬ 
cilities.  Finally,  all  facts,  rules,  subtleties  and  interactions  pertaining  to  the 
maintenance  problem  are  described. 

•  Chapter  III  starts  with  a  review  of  published  analytic  models  and  results  related  to 
theoretical  maintenance  problems.  These  models  are  either  designed  to  solve  dif¬ 
ferent  problems,  or  they  are  purely  analytic  in  nature  and  tend  to  describe  idealized 
systems.  Section  C  of  Chapter  III  describes  the  basic  flow  model  that  is  studied  in 
this  thesis,  and  which  is  shown  in  Figure  6. 

•  Because  of  the  complexity  of  the  interaction  between  a  four-indenture-level  weapon 
system  and  a  three-echelon  maintenance  system,  simulation  of  stochastic  processes 
is  used  as  the  primary  modeling  tool.  Chapter  IV  contains  an  overview  of  available 
simulation  models,  with  emphasis  on  "TIGER",  a  FORTRAN-based  program  used 
by  the  Naval  Sea  Systems  Command  in  the  U.S.Navy. 
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•  Due  to  the  fact  that  there  is  no  directly  applicable  simulation  model  for  the  given 
problem,  Chapter  V  shows  the  necessary  input  modifications  in  the  use  of  TIGER 
to  obtain  useful  results  for  the  decisions  to  be  made. 

•  Chapter  VI  contains  the  results  of  the  application  of  TIGER,  and  describes  its 
major  shortcomings  when  used  for  the  given  problem.  Basically  it  can  offer  only  a 
fixed  number  of  input  choices  (due  to  the  computer  language  used),  restricting  the 
user  to  small  weapon  systems,  and  it  does  not  enable  the  modeling  of  the  back-flow 
of  repaired  components  of  repaired  systems  to  their  respective  stocks. 

•  It  appears  that  these  problems  could  be  overcome  by  using  a  modem,  object- 
oriented  simulation  language  like  MODS1M-11.  Chapter  VII  describes  how 
MODSIM  can  be  used  for  solving  the  given  problem,  and  shows  compiled  code  for 
some  of  the  objects  in  Appendix  C.  A  full-scale-development  of  a  simulation  model 
for  the  complex  real  two-system-interaction  world  is  beyond  the  scope  of  this  the¬ 
sis. 

•  This  thesis  ends  with  suggestions  in  Chapter  VIII  for  the  necessary  future  work  to 
be  done  on  this  topic,  which  might  help  both  to  increase  the  efficiency  of  the  lo¬ 
gistic  part  of  the  Weapon  Acquisition  Process  and  to  improve  the  management  of 
the  available  financial  resources  within  the  defense  budget  of  the  Federal  Republic 
of  Germany. 
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II.  THE  MILITARY  ENVIRONMENT  OF  THE  UPCOMING  DECISION 


In  this  chapter  the  military  environment  of  the  decision  model  is  defined  by  pre¬ 
senting 

•  the  modular  structure  of  electronic  equipment,  applied  in  the  weapons  acquisition 
process  of  the  Federal  Armed  Forces  Germany 

•  the  general  maintenance  concept  to  provide  support  to  these  electronic  systems  in 
the  German  Army[Ref.  2] 

•  the  command  structure  of  the  German  Army  with  combat,  combat  support,  com¬ 
munication  and  logistic  forces. 

A.  MODULAR  STRUCTURE  OF  ELECTRONIC  EQUIPMENT 

Electronic  weapon  systems  in  the  notation  of  the  German  Armyl  include  weapon 
systems  with  essential  electronic  components  (e.g.  battle  tanks  with  an  electronic 
weapon  guidance  system,  Artillery  weapons  controlled  by  a  data  link  system),  command- 
and  control  systems,  signal-  and  communication  systems  (e.g.  AUTOVON  (US)  / 
AUTOKO  (GE)),  reconnaissance  systems  (e.g.  Artillery  reconnaissance  radar)  and  sig¬ 
nal-  and  communication-  intelligence  systems.  All  these  electronic  weapon  systems  are 
generally  structured  in  5  indenture  levels2  as  seen  in  Figure  1  on  page  5: 

1 .  The  complete  system  itself  -  as  an  illustrative  example  we  will  look  at  a  Battle  Tank 
assumed  to  be  developed. 

2.  Subsystems  or  A-Units  arc  functional  units  or  self  contained  units  within  a  weapon 
system.  In  our  example  the  (non-electronic)  Gun .  the  (electronic)  Weapon  Guidance 
Subsystem,  the  (electronic)  Command-  and  Control  Subsystem  and  the  ("semi"- 
electronic)  Power  Supply  Subsystem  are  A-Units. 

3.  Assemblies  or  B-Units  are  integral  parts  of  A-Units.  Target  Data  Storage  and  Data 
Display  Terminal  are  B-Units  of  the  Command-  and  Control  Subsystem. 

4.  Subassemblies  or  C-Units  and 

5.  Elements  or  D-Units  are  both  the  smallest  replaceable  components  of  a  weapon 
system.  The  "black  box"  Updated  Target  Data  Memory  is  a  C-Unit  (subassembly) 
that  will  not  be  repaired  in  the  field,  the  Microchip  A4512  is  a  D-Unit  (element)  that 
can  not  be  repaired  at  all. 


1  This  structure  is  slightly  different  from  that  used  by  the  US  Army  in  the  Logistic  Support 
Analysis  (LSA)  procedures  [Ref.  1,  p.2-1 7|. 

2  The  term  indenture  level  is  also  used  by  the  US  Army  to  address  the  different  levels  of  a 
"hardware  generation  breakdown"  [Ref.  1,  p.  2] 
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Figure  1.  Modular  Structure  of  Electronic  Equipment  in  the  German  Army 

B.  MAINTENANCE  CONCEPT  FOR  ELECTRONIC  EQUIPMENT 

In  general,  the  maintenance  of  any  electronic  weapon  system  is  performed  both  by 
military  personnel  for  conventional  technology  (engine,  steering  system  etc.)  and  by 
military  personnel  for  electronic  technology.  In  this  paper  we  concentrate  only  on  the 
maintenance  concept  for  electronic  equipment,  shown  in  Table  1  on  page  6  [Ref  2]. 
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Table  1.  MAINTENANCE  CONCEPT  FOR  ELECTRONIC  MATERIEL 


Level  of 
System 
Structure 

Test  Procedure 

Maintenance  Procedure 

System 

User  (Notation  in  the  German  Army:  Maintenance  Echelon  1) 

Built-In-Test-Equipment  (BITE) 
Technical  Manuals 

Report  of  defective  A-Unit  to 
Organizational  Maintenance 

A-Units 

On-System  modular  maintenance 
by  replacement  of  Line  Replacea¬ 
ble  Units  (LRU):  B-Units;  C- 
Units  and  D-Units  if  appropriate 

Organizational  Maintenance  (Maintenance  Echelon  2) 

B-Units 

LRU-Test  by  Test,  Measurement 
and  Diagnostic  Equipment 

(TMDE) !  Technical  Manuals 

Off-System  modular  maintenance 
of  defective  LRU  by  replacement 
of  C-Units  and  D-Units 

Intermediate  Maintenance  (Maintenance  Echelon  3) 

C-Units 

Technical  Manuals,  Contractoi 
manuals,  special  equipment 

Repair  of  C-Units  by  replacement 
of  D-Units 

Depot  Maintenance  (Maintenance  Echelon  4)  or  commercial  mainte¬ 
nance  (Maintenance  Echelon  4) 

D-Units 

no  test  -  no  repair  -  recycle  or  discharge 

C.  MILITARY  COMMAND  STRUCTURE  OF  THE  GERMAN  ARMY 

Germany  is  undergoing  extensive  political,  economical  and  social  changes  since  the 
unification  on  October  3rd  1990.  As  a  consequence,  the  military  structure  of  the  Federal 
Armed  Forces  is  subject  to  changes  in  the  years  ahead.  The  structure  presented  in  the 
next  paragraphs  is  the  general  structure  of  the  Army,  which  will  persist  whatever 
changes  and  reductions  might  occur.  Specific  details  and  exact  quantities  are  omitted 
since  they  are  irrelevant  for  the  stated  decision  problem. 

1.  Combat,  Combat  Support  and  Communication  Forces 

The  highest  command  level  below  the  Federal  Ministry  of  Defense,  Headquarter 
of  the  Army,  at  BONN  is  an  Army  Corps.  The  general  command  structure  of  an  Army 
Corps3  is  shown  in  Figure  2  on  page  7. 


3  There  are  3  Army  Corps  in  the  German  Army 


6 


Figure  2.  Command  Structure  of  a  German  Army  Corps 


While  an  electronic  weapon  system  used  in  the  Combat  Forces  is  mostly  de¬ 
ployed  in  large  numbers  (e.g.  there  will  be  some  thousand  battle  tanks  with  electronic 

subsystems),  the  many  different  electronic  weapon  systems  deployed  in  the  combat 

/ 

support  and  communication  forces  often  consist  of  only  a  small  number  of  units  (e.g. 
there  will  be  only  some  15  units  of  a  communications-  and  signal-intelligence- system 
within  the  entire  Army). 

2.  Logistic  Forces  (Maintenance  Component) 

The  structure  of  the  maintenance  component  is  presented  completely,  but  the 
supply  component  is  shown  only  as  far  as  it  is  under  operational  control  of  the  mainte¬ 
nance  component. 

a.  Organizational  Maintenance 

Organizational  Maintenance  (Maintenance  Echelon  2),  both  for  conven¬ 
tional  materiel  and  for  electronic  materiel  (EloMat),  is  provided  by  a  Maintenance 
Platoon  for  every  Batallion,  and  by  a  Maintenance  Group  for  every  Company  that  is 
not  under  operational  control  of  a  Batallion  (See  Figure  3). 
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Figure  3.  Structure  of  the  Organizational  Maintenance 
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The  quantity  of  the  maintenance  personnel  is  determined  by  the  needed  capacity,  but 
at  least  1  soldier  has  to  be  available  at  each  Batallion  Company  for  each  type  of  weapon 
system.  There  is  no  supportive  exchange  of  maintenance  personnel  between 
Batallions  Companies.  The  skill-level  has  "only”  to  be  appropriate  for  localizing  defec¬ 
tive  LRL'4  by  using  BITE  or  straightforward  traditional  techniques,  and  for  replacing 
‘  them.  Jobs  requiring  higher  qualifications  might  be  completed,  if  the  personnel  can  per¬ 

form  them  with  the  available  tools  and  within  the  capacity  limits  of  the  uniu 
b.  Intermediate  Maintenance 

The  structure  of  the  Maintenance  Troops  5  (Maintenance  Echelon  3)  is 
shown  in  Figure  4  on  page  10. 

Each  Army  Corps  has  2  active  Maintenance  Batallions,  servicing  both  the 
conventional  materiel  and  the  electronic  materiel  (EloMat)  of  the  Corps'  Combat  Sup¬ 
port  Forces  and  Communication  Forces.  Each  Division  has  1  Maintenance  Batallion;  2 
Companies  service  the  conventional  materiel  of  the  Division's  Combat  Support  Forces 
and  Communication  Forces;  1  Company  for  electronic  materiel  services  both  the  Divi¬ 
sion's  troops  and  the  electronic  materiel  of  the  Brigades  -  though  every  Brigade  has  its 
own  Maintenance  Company,  there  is  no  service  for  electronic  materiel  on  the  Brigade's 
command  level. 

The  quantity  of  the  maintenance  personnel  is  determined  by  the  needed  ca¬ 
pacity  and  the  number  of  different  fields  of  technology  applied  in  the  new  system  ("pure" 
electronic,  optronic,  Laser,  Radar  etc.).  Many  jobs  are  performed  by  mobile  mainte¬ 
nance  teams,  and  at  least  2  soldiers  have  to  be  available  at  each  Maintenance 
Batallion  Company  (EloMat)  for  each  type  of  supported  electronic  weapon  system 
and  or  each  technology  used.  There  is  no  supportive  exchange  of  maintenance  person¬ 
nel  between  Corps  and  or  Divisions.  Though  localization  of  defective  C-  and  D-Units 
for  certain  systems  is  performed  by  different  personnel  applying  the  complex  Test, 
Measurement  and  Diagnostic  Equipment  (TMDE),  the  skill-level  generally  has  to  be 
appropriate  for  localizing  defective  C-  and  D-Units  using  traditional  techniques,  and  for 
replacing  these  units.  Again,  jobs  requiring  higher  qualifications  might  be  completed,  if 
the  personnel  can  perform  them  with  the  available  tools  and  within  the  capacity  limits 
»  of  the  unit. 


4  See  pages  xi  and  xii  for  a  List  of  Abbreviations  and  Acronyms 

5  based  on  the  actual  structure  of  the  Army  in  the  10  Western  States  of  Germany  (the  former 
West  Germany) 
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Figure  4.  Structure  of  the  Maintenance  Troops 
c.  Depot  Maintenance 

Materiel  with  damages  requiring  work  in  Maintenance  Echelon  4  leaves  the 
combat  zone  and  is  transported  to  central  repair  shops  at  Army  Maintenance  Installa¬ 
tions,  at  depots  or  at  commercial  facilities. 


d.  Interactions 

While  personnel  of  the  Organizational  Maintenance  might  perform  jobs  of 
a  higher  Maintenance  Echelon  if  capacity  constraints,  skill  levels  and  available  tools  al¬ 
low,  maintenance  teams  of  the  Maintenance  Troops  can  be  ordered  by  their  operational 
command  to  work  on  surplus  jobs  on  Maintenance  Echelon  2,  if  this  is  the  only  way  to 
increase  the  availability  of  a  certain  electronic  system  at  a  certain  military  unit.  How¬ 
ever,  this  regulation  will  not  be  regarded  in  this  model,  because  it  should  be  constrained 
to  emergency  situations. 

e.  Replacement  Parts  Supply  and  Storage 

All  considerations  about  replacement  of  LRU  (B-Units /Assemblies)  at 
Maintenance  Echelon  2  and  C-  (Subassemblies)  and  D-Units  (Elements)  at  Maintenance 
Echelon  3  are  based  on  the  immediate  availability  of  replacement  parts  at  these  mainte¬ 
nance  facilities.  Supply  of  these  parts  only  on  demand  would  take  far  too  long  to  guar¬ 
antee  shortest  possible  times  to  repair. 

To  decrease  the  down  time  of  a  weapon  system,  each  Maintenance  Batallion 
(intermediate  maintenance  level)  has  a  Direct  Exchange  Stock  (DES)  for  B-Units,  and 
if  appropriate,  also  for  selected  C-  and  D-Units  (see  Table  1  on  page  6).  The  military' 
user  delivering  a  defective  B-Unit  immediately  receives,  if  available,  an  intact  B-Unit  in 
exchange,  while  the  defective  B-Unit  will  be  added  to  the  DES  after  repair.  So  the 
downtime  for  a  B-Unit  (consequently  the  downtime  of  the  failed  system  after  being  di¬ 
agnosed  and  before  actually  being  repaired)  is  reduced  to  the  amount  of  transportation 
time  between  military  user  and  its  assigned  Maintenance  Batallion.  Of  course,  the 
Maintenance  Batallions  also  have  a  stock  for  the  C-  and  D-Units  needed  for  repair  of 
the  defective  B-Units. 

Consequently,  the  model  has  to  consider  the  necessary  stock  levels  at  the 
facilities  of  Maintenance  Echelon  2  and  3,  but  not  further  back  in  the  line  of  supply 
which  will  be  assumed  to  have  unlimited  capacity. 

D.  CONSEQUENCES  FOR  THE  UPCOMING  DECISION 

Resulting  from  the  facts  presented  above,  certain  range  limitations  for  the  following 
decision  areas  ha%e  to  be  observed: 

1.  Organizational  Maintenance 

Due  to  the  concept  of  Organizational  Maintenance,  each  Batallion; Company 
supplied  with  a  certain  electronic  weapon  system  has  to  be  able  to  perform  repair  jobs 
on  its  own  equipment  at  Maintenance  Echelon  2.  So  the  decision  to  be  made  is  not 
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about  the  fact  of  creating  an  installation  at  all,  but  "only”  about  the  number  of  repair 
personnel,  which  will  be  at  least  1. 

To  keep  the  Organizational  Maintenance  as  highly  mobile  as  the  weapon  system 
itself,  a  spare  stock  of  A-Units  generally  will  not  be  kept  at  the  organizational  level. 
However,  establishing  such  a  (limited)  spare  stock  might  be  one  way  to  increase  the 
system  availability,  and  can  be  one  feature  of  the  upcoming  decision. 

2.  Intermediate  Maintenance 

Because  some  electronic  weapon  systems,  especially  those  deployed  in  very  small 
numbers,  are  designed  to  avoid  any  work  at  Maintenance  Echelon  3,  the  number  of  re¬ 
pair  personnel  for  a  certain  weapon  system  at  Maintenance  Echelon  3  might  be  0.  If 
Maintenance  Echelon  3  is  appropriate,  there  are  several  choices  for  the  location  of 
maintenance  facilities.  In  Table  2  the  possible  mutual  exclusive  alternatives  are  shown. 
In  these  cases  stock  levels  for  both  the  DES  (Direct  Exchange  Stock)  and  the  C-  and 
D-Units  stock  have  to  be  determined. 


Table  2.  MAINTENANCE  FACILITIES  AT  MAINTENANCE  ECHELON  3 


Command  level  of  system  de¬ 
ployment 

Number  of  maintenance  facilities 

Sum  for 
entire 
Army 

Brigade 

1  per  Division 

12 

Brigade  +  Division 

1  per  Division 

12 

Division 

1  per  Division 

12 

Division  +  Corps 

1  per  Corps 

3 

1  per  Division  and  per  Corps 

15 

Corps 

1  per  Corps 

3 

Brigade  +  Division  +  Corps 

1  per  Corps 

3 

1  per  Division  and  per  Corps 

15 

3.  Depot  Maintenance 

The  decision  about  the  quantity  of  the  maintenance  personnel  at  the  depot  level 
is  not  as  important  as  at  the  organizational  and  intermediate  level  at  this  stage  of  the 
decision  problem.  Therefore  this  problem  will  not  be  addressed,  nor  that  of  spare  stock 
levels  at  Depot  Maintenance  facilities  which  will  be  assumed  to  be  infinite. 
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III.  THE  THEORETICAL  BASIS  FOR  THE  UPCOMING  DECISION 


A.  GENERAL  APPROACHES  FOR  MAINTENANCE  CONCEPTS 

A  survey  of  the  articles  published  in  the  respective  journals  within  the  last  years 
shows  numerous  studies  and  papers  about  the  modeling  of  optimal  maintenance  policies 
for  single-  and  multi-unit  electronic  and  non-electronic  systems;  for  example  see  [Ref. 
3,  4,  5,  6  and  7].  An  overview  especially  about  models  for  multi-unit  systems  is  given  in 
[Ref.  8]. 

These  "...  Multi-unit  maintenance  models  are  concerned  with  optimal  maintenance 
policies  for  a  system  consisting  of  several  units  of  machines  or  many  pieces  of  equip¬ 
ment,  which  may  or  may  not  depend  on  each  other  ...  The  objective  is  to  find  optimal 
repair  rates  (i.e.,  number  of  repairmen,  number  of  repair  facilities,  etc.)  ..."[Ref.  8]. 

Many  of  these  models  consider  specialties  needed  in  the  defined  military  environ¬ 
ment  like 

•  more  than  one  repair  facility  in  the  system 

•  failed  equipment  has  to  be  sent  to  a  certain  repair  facility 

•  multi-echelon  maintenance  structures. 

So,  the  reader  might  ask,  are  we  to  invent  the  wheel  again  ?  There  are  three  main 
reasons  for  a  different  approach  to  solve  the  given  real-world  problem. 

1.  Distributions  for  Failure  and  Repair  Times 

In  many  models  mathematical  procedures  are  simplified  by  assuming  an  expo¬ 
nential  distribution  for  both  the  times  between  failures  and  the  repair  times.  Especially 
regarding  electronic  components  having  a  high  reliability,  this  assumption  may  be  un¬ 
realistic  for  the  times  between  failures.  We  will  observe  a  high  mean  time  between  failure 
(MTBF)  with  very  few  failure  times  being  close  to  zero.  Jardine  and  Buzacott  [Ref.  6  , 
p.286]  even  state  that  it  is  realistic  to  assume  that  there  are  no  failures  at  all  between  the 
start-up  of  the  observed  equipment  (y  =  0)  and  some  time  y  >  0. 

The  assumption  of  exponential  distribution  may  or  may  not  be  realistic  for  the 
repair  times.  The  exponential  distribution  for  repair  times  says  that  the  probability  for 
completion  of  a  repair  job  in  the  next  k  units  of  time  does  not  depend  on  how  long  the 
repair  job  has  been  worked  on  already  -  not  too  realistic  for  some  types  of  repair!  There 
will  be  a  minimum  time  for  each  repair  job  (receiving  the  job,  preparing  the  work  place, 
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performing  test  and  measurement  procedures,  performing  the  genuine  repair  etc.). 
Though  there  will  be  no  values  close  to  zero,  we  will  observe  a  highly  skewed  distribution 
with  a  lot  of  small  TTR- values  (caused  by  easy  detectable  mechanical  or  thermal  dam¬ 
ages  followed  by  simple  replacement  of  the  damaged  component)  and,  nevertheless,  a 
non-negligible  number  of  observations  with  distinctive  higher  values  (caused  by  short- 
circuits  etc.).  Though  some  studies  (e.g.  see  in  [Ref.  8  ,p.5])  use  general  repair  times,  the 
assumption  of  exponentially  distributed  TTR  seems  reasonable,  when  the  nature  of  the 
repair  is  random  due  to  the  random  type  of  failure. 

2.  Optimality  Criteria 

Another  great  drawback  is  the  use  of  all  kinds  of  costs  as  optimality  criteria  to 
achieve  an  optimized  maintenance  concept.  This  is  legitimate  and  appropriate  in  all  de¬ 
scribed  problems,  especially  in  cases  regarding  not  only  costs  for  repair  personnel  and 
repair  facilities,  but  also  costs  for  spare  part  inventories  and  costs  in  form  of  lost  reven¬ 
ues  due  to  downtimes  caused  by  failures.  While  lost  revenue  is  irrelevant  in  the  military 
environment  (though  a  lost  battle  has  an  enormous  economic  impact),  most  other  types 
of  costs  are  not  applicable  in  the  described  real-w'orld  situation,  because  they  are  neither 
known  nor  can  be  acquired  in  this  early  stage  of  the  acquisition  process. 

Other  models  additionally  or  exclusively  use  the  availability  of  the  system  as  a 
decision  criterion  -  for  example  see  [Ref.  7,  p.  551).  This  approach  is  promising  pertain¬ 
ing  to  the  given  problem. 

3.  Available  Information 

Due  to  the  fact  that  the  future  system  is  not  defined  exactly  at  this  point  of  time, 
we  have  to  make  a  decision  under  extreme  uncertainty  .  Because  we  do  not  have  any  test 
results  for  single  Subsystems,  Assemblies  or  Subassemblies  (with  the  exception  of 
standardized  equipment),  we  have  to  create,  in  the  most  controlled  way  possible, 
"probable  probability  distributions"  for  the  times  between  failures  for  each  proposed  and 
yet  to  be  developed  component  of  the  planned  System  Breakdown  Structure  (SBS). 
Based  on  this  "solid  ground",  we  have  to  come  to  a  recommendation  for  the  future 
maintenance  concept  for  this  new  electronic  equipment. 

Cho  and  Parlar  [Ref.  8,  p.3]  realize1  that  dilemma  by  stating  "...  Very  few  papers 
have  been  written  on  the  area  of  maintenance  models  with  incomplete  information  ...". 
The  need  for  further  research  on  this  field  within  the  military  environment  is  emphasized 
in  a  1984  Notice  of  the  Secretary-  of  the  Navy,  D.E.  Mann  [Ref.  9,  p.87]:  "Although  there 
is  considerable  uncertainty  early  in  the  acquisition  process,  every  effort  must  be  made 
to  use  the  best  available  data  and  techniques  in  developing  estimates." 
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B.  IDEALIZED  APPROACH  FOR  GIVEN  PROBLEM 


1.  Distributions  for  Time  Between  Failure 

Regarding  possible  failure  scenarios  and  evaluating  the  actual  literature  (e.g.  see 
[Ref.  6]),  the  Weibull  and  the  Gamma  distribution  are  the  most  appropriate  to  use  for 
time  between  failure. 

The  Weibull  density  function  has  the  following  form  [Ref.  6,  10  and  11],  also 
used  by  the  statistical  package  GRAFSTAT  [Ref.  12]: 

=  T  (t)"1  e~^‘  ;0</<oo,c>0,a>0 


and  its  cumulative  distribution  function  has  the  form: 

\-e~(±y 


The  Gamma  density  function  has  the  following  form  [Ref.  13,  p.  165,  and  12]: 
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e  p  ;  0  ^  <  oo,  /?  >  0,  a  >  0 


Us  cumulative  distribution  function  can  not  be  obtained  in  closed  form. 

Using  appropriate  shape-parameters  ("c"  for  the  Weibull,  "/?"  for  the  Gamma) 
and  scale-parameters  (a),  both  distributions  are  highly  flexible  to  fit  Exponential  and 
Normal  distributions,  and  any  other  distribution  being  "humped  in  the  middle".  This 
"flexibility"  is  shown  in  Figure  5  on  page  16. 

Jardine  and  Buzacott  [Ref.  6]  use  the  3-parameter  Weibull  density  function  with 
the  third  parameter  "y",  the  location  parameter.  This  is  not  appropriate  in  our  situation. 
Though  the  number  of  failures  of  one  component  occurring  within  a  short  time  will  be 
very  small,  this  possibility  has  to  be  regarded  because  there  might  be  imperfect  repairs. 
Pertaining  to  this  fact  many  studies  assume  that  repaired  components  are  as  good  as  new 
(e.g.  in  [Ref.  7]),  which  will  not  be  realistic  in  a  military  environment  -  neither  in  war  nor 
in  peacetime.  Consequences  of  imperfect  repair  on  system  reliability  are  shown  in  [Ref. 
14]. 

So  the  approach  to  the  given  real-world  problem  described  here  will  use  either 
the  2-parameter  Weibull  or  the  Gamma  distribution  to  model  the  time  between  failures 
and  the  exponential  distribution  to  model  the  repair  times. 
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DENSITY  FUNCTIONS  FOR  FAILURES  AND  REPAIR 


WEBULL  DCTOUTSN.  XLPHA-72C 


QMAM  OBTIBKmON,  ALPHMBE/W3D 


§ 


m 

imuMctHOua) 


Figure  5.  The  Flexibility  of  the  Weibull  and  Gamma  Density  Functions 

2.  Links  between  Failure  and  Repair  Times 

Many  authors  assume  exponentially  distributed  repair  times,  but  most  of  them 
also  assume  the  same  repair  time  distribution  for  all  components  which  are  subject  to 
failure.  This  is  partially  unrealistic  for  the  described  problem.  There  is  not  only  a  differ¬ 
ence  in  repair  times  between  changing  a  defective  Subsystem  in  Organizational  Mainte¬ 
nance  (which  can  be  assumed  to  be  relatively  constant  due  to  'design  to  quick 
replacement"),  and  finding  the  defective  Subassembly  or  Element  within  an  Assembly 
when  repairing  it  in  Intermediate  Maintenance  (which  could  be  covered  by  assumption 
of  maintenance  echelon  specific  repair  times  -  a  concept  used  by  Madu  in  [Ref.  3,  p.  959 
-  960]),  but  there  are  also  decisive  differences  in  repair  times  between  different  technol- 
ogies  at  Intermediate  Maintenance.  Each  specified  component  "X"  of  the  future  system 
will  be  characterized  by  3  parameters: 

1.  Cf-value  for  the  "probable"  distribution  for  times  between  failures  for  component 
"X"  (in  case  of  the  Gamma  distribution  the  /Rvalue) 

2.  value  for  the  "probable"  distribution  for  times  between  failures  for  component 
"X" 
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3.  MTTRX,  the  "probable"  technology  dependent  MTTR  for  component  "X" 

Pertaining  to  this  necessary  approach  no  literature  at  all  was  to  be  found. 

3.  Source  of  Information 

With  the  future  system  just  being  defined  in  terms  of  a  SBS  (system  breakdown 
structure),  there  are  no  data  available  for  the  necessary  values  of 
cx  or  px,  ax  and  MTTRX.  Jardine  [Ref.  6,  p.288]  mentions  three  basic  approaches  to  es¬ 
timate  these  data.  While  the  third  approach  -  models  based  on  physical,  chemical  or 
other  mechanisms  of  failure  -  is  not  appropriate  due  to  the  uncertainty  of  the  engineering 
design  at  the  relevant  point  in  time,  a  combination  of  the  other  two  approaches  seems 
applicable: 

1.  Analysis  of  empirical  data  on  a  similar  design 

2.  Prediction  of  system  reliability  from  component  reliability 

With  each  single  repair  job  done  at  Maintenance  Echelon  2,  3  or  4  within  the 
German  Army,  a  lot  of  data  are  gathered  offering  information  about  the  proceeding  of 
the  job  over  time.  Active  maintenance  times  (AMT  =  TTR  =  ART  (Active  Repair 
Time))  and  the  MTTR  can  be  obtained  directly.  Administrative  delay  times  (ADT), 
caused  by  maintenance  system  inherent  procedures  and  geographical  distances,  and  lo¬ 
gistic  delay  times  (LDT),  caused  by  ordering  and  waiting  for  spare  parts  not  in  stock  at 
the  maintenance  facility  can  be  estimated.  Throughout  the  lifetime  of  each  single  weapon 
system,  data  are  gathered  about  down  times  from  which  the  times  between  failures 
(TBF)  can  be  obtained.  From  these  known  TBF  data  the  appropriate  a,  /?  and  c-values 
can  be  obtained  by  using  GRAFSTAT  [Ref.  12,  "FITTING  PROBABILITY 
DISTRIBUTIONS"!. 

Though  we  do  not  know  the  exact  characteristics  of  the  components  of  the  fu¬ 
ture  weapon  system,  we  can  assume  that  these  values  are  not  too  different  for  compo¬ 
nents  with  similar  functional  characteristics  (e.g.  antennas,  terminal  keyboards,  displays, 
RADAR-emitters,  military  computers  etc.)  and  within  the  same  level  of  technology’, 
which  have  already  provided  plenty  of  realistic  data  from  the  actual  use  in  the  real 
(peacetime)  world.  Definite  sources  of  trouble  will  be  a  differentiation  of  similar  com¬ 
ponents  originating  from  different  contractors,  the  evaluation  of  offered  "next  technol¬ 
ogy  generation"  components  and  the  adaptation  of  the  data  to  a  wartime  scenario 
(further  research  has  to  be  done  on  these  features). 
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If  a  totally  new  functional  configuration  will  be  introduced,  the  subcomponents 
still  will  offer  a  chance  to  find  appropriate  values,  from  which  the  reliability  for  the  next 
higher  SBS-level  can  be  computed. 

4.  Optimality  Criterion 

As  pointed  out  in  1 1 1. A. 2.,  system  availability  is  one  meaningful  optimality  cri¬ 
terion  for  evaluating  future  maintenance  performance  problems.  This  availability  defi¬ 
nitely  depends  upon  the  reliability  of  the  system,  but  can  be  increased  decisively  by  an 
appropriate  maintenance  system.  Before  proceeding  further,  we  need  to  recall  the  defi¬ 
nitions  and  characteristics  of  reliability  and  availability. 

•  Reliability 

The  probability  that  a  weapon  system  will  perform  its  intended  function  for  a 
specified  period  of  time  under  stated  conditions  [Ref.6,  p.285,  15,  p.32,  and  16,  p.20]. 

The  reliability  function  R(t)  is  well  defined  as 

f  XAt)dt 

whereat)  is  the  probability  density  function  of  the  time  between  failures.  Therefore  the 
reliability  function  R^t)  for  the  general  form  of  the  Weibull  distribution  has  the  form 
(c  >  0,  a  >  0): 


Although  there  is  no  closed  form  for  the  reliability  function  for  the  Gamma  distribution, 
we  could  use  the  incomplete  Poisson  Sum  for  integer  values  of  a  to  compute  R(t). 

The  reliability  values  obtained  by  this  approach  depend  on  2  features: 

•  the  distribution  of  the  times  between  failures,  which  is  independent  from  the  applied 
maintenance  concept 

•  the  length  of  the  specified  period  of  time,  which  can  be  "varied  to  achieve  any  reli¬ 
ability  value  desired"  (R  -» 0  for  i  -*  oo,  R  -*  1  for  /  -» 0) 

Due  to  the  independence  from  the  maintenance  concept,  and  due  to  possible 
bias  by  "conveniently"  choosing  the  length  of  the  time  period,  reliability  is  not  suitable 
as  an  optimality  criterion  in  the  given  problem. 
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•  Availability 

The  probability  that  a  weapon  system  is  in  the  operable  state  at  any  point  of  time 
when  used  under  stated  conditions[Ref.  15  ,  p.29  and  17,  p.l9j. 

A  generally  used  computational  formulation  of  availability  is  the  operational 
availability  being  defined  [Ref.  17]  as 

A  MTBM 

°  MTBM  +  MDT 

where  MTBM  is  the  Mean  Time  Between  Maintenance  and  MDT  is  the  Mean  Down 
Time.  MDT  itself  is  the  sum  of  MAMT  (Mean  Active  Maintenance  Time),  LDT  (Lo¬ 
gistics  Delay  Time)  and  ADT  (Administrative  Delay  Time).  Considering  a  long  period 
of  time  this  approach  offers  an  average  availability,  which  strongly  depends  -  via  MDT 
-  on  the  applied  system  specific  maintenance  concept.  However,  MDT  itself  can  not  be 
handled  as  an  average  value,  because  this  approach  would  not  take  into  account  worst 
case  scenarios,  where  many  components  might  fail  within  a  short  period  of  time,  im¬ 
posing  decisively  more  workload  onto  the  maintenance  system  in  some  periods  of  time 
than  under  the  mean  value  approach. 

This  average  availability  is  the  appropriate  optimality  criterion  for  the  given 
problem.  Note  that  there  is  a  decisive  difference  between  the  availability  (combat  readiness) 
of  a  military  unit,  and  the  availability  of  a  single  unit  of  a  weapon  system  within  this  mili¬ 
tary  unit.  Only  the  latter  will  be  covered  here. 

C.  THE  STOCHASTIC  MODEL  OF  THE  MAINTENANCE  SYSTEM 

The  system  specific  maintenance  system,  determined  by  the  number  of  deployed 
systems  and  introduced  in  I.B.,C.  and  D.,  can  be  described  as  a  stochastic  network, 
shown  in  Figure  6  on  page  20  (See  in  comparison  also  [Ref.  18,  p.  18]). 

1.  Fixed  Parameters 

Its  characterizing  fixed  parameters  are  defined  in  Table  3  on  page  21.  All  given  times 
are  in  hours,  based  on  a  (peacetime)  average  of  7  hours  of  use  per  day,  5  days  of  use  per 
week  and  48  of  these  weeks  per  year.  E.g.,  ADT3  =  35  means  a  delay  of  35  hours  of 
simulation  time,  which  is  about  a  week  in  peacetime,  but  1  day  and  1 1  hours  in  a  war¬ 
time  situation  with  a  time  of  use  of  24  hours  a  day,  7  days  a  week  and  52  weeks  a  year. 
So  these  times  are  realistic  for  all  possible  scenarios. 

2.  Decision  Orientated  Variable  Parameters 

The  variables  shown  in  Table  4  on  page  22  are  the  data  upon  which  a  decision 
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Figure  6.  Stochastic  Model  of  the  Maintenance  System 


Table  3.  FIXED  PARAMETERS  OF  THE  MAINTENANCE  SYSTEM 


Parameter 

Value  (hours) 

Description 

S  Total 

These  data 
can  be  ob¬ 
tained  from 
the  current 
Acquisition 
Decision 
Memoran¬ 
dum  (ADM) 

T otal  number  of  systems  deployed 

Sun,, 

Number  of  systems  deployed  in  one  unit 

I'D 

Number  of  units  per  Division  supplied  with  the  sys¬ 
tem 

Dc 

Number  of  Divisions  per  Corps  supplied  with  the 
system 

l’c 

Number  of  units  under  direct  operational  command 
of  a  Corps  supplied  with  the  system 

MARTa 

2 

Mean  Active  Repair  Time  for  an  A-Unit  by  replace¬ 
ment  of  a  B-Unit  (see  III.B.2.)  or  by  performance  of 
simple  repair  without  replacement 

MART B 

2  -  14 

Active  Repair  Time  for  a  B-Unit  by  replacement  of 

C-  and  D-L'nits  (error  location  and  actual  replace¬ 
ment)  is  dependent  on  the  used  technology 

TDTst0Ck 

1 

Number  of  delay  hours  caused  by  logistic  delay  per 
repair  job  in  all  Maintenance  Echelons  if  required 
spare  part  is  in  stock  at  maintenance  facility 

TDT DES 

10 

Number  of  delay  hours  caused  by  logistic  delay  per 
repair  job  in  Maintenance  Echelon  2  if  required  As¬ 
sembly  has  to  be  obtained  from  DES  at  Intermediate 
Maintenance 

L  D  Tsupp/y 

35 

Number  of  delay  hours  caused  by  logistic  delay  per 
repair  job  in  Maintenance  Echelon  3  if  required  spare 
part  is  not  in  stock,  but  available  in  the  military  sup¬ 
ply  line 

adt2 

2 

Number  of  hours  caused  by  administrative  delay  per 
repair  job  in  Maintenance  Echelon  2 

adt3 

35 

Number  of  hours  caused  by  administrative  delay  per 
repair  job  in  Maintenance  Echelon  3  (including  trans¬ 
port  times) 

a  decision  has  to  be  made.  Realistic  values  will  be  chosen  as  initial  input  data&,  and  will 
have  to  be  readjusted  for  each  new  run  of  the  simulation. 


6  What  is  realistic  is  determined  by  already  known  budgetary  constraints,  general  personnel 
policies  etc.,  and  depends  strongly  upon  the  knowledge  of  an  user  experienced  in  his  functional 
specialty. 
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Table  4.  VARIABLE  PARAMETERS  OF  THE  MAINTENANCE  SYSTEM 


Parameter 

Description 

R, 

Number  of  repair  personnel  at  Maintenance  Echelon  2 

Number  of  spare  parts  of  component  "name"  in  stock  at  Mainte¬ 
nance  Echelon  2 

Rid 

Number  of  repair  personnel  at  Maintenance  Echelon  3  (Division) 

Number  of  spare  parts  of  component  "name"  in  stock  at  Mainte¬ 
nance  Echelon  3  (Division) 

R-ic 

Number  of  repair  personnel  at  Maintenance  Echelon  3  (Corps) 

Number  of  spare  parts  of  component  "name"  in  stock  at  Mainte¬ 
nance  Echelon  3  (Corps) 

3.  Additional  Variable  Parameters 

Some  military  performance  requirements  for  a  new  system  can  be  looked  upon 
as  variable  parameters.  If  the  required  availability  can  not  be  achieved  within  the  real¬ 
istic  range  of  the  decision  variables,  reruns  of  the  simulation  with  relaxed  requirements 
can  offer  more  insight  into  the  problem.  In  Table  5  on  page  22  the  most  important  pa¬ 
rameter  of  this  kind  is  shown. 

An  example  for  this  feature  is  any  electronic  device  backed  up  by  a  mechanical 
device,  where  the  electronic  device  may  have  DTm„  =  14,  whereas  for  example  commu¬ 
nication  devices  will  generally  have  DTm„  =  0  . 

Table  5.  VARIABLE  REQUIREMENT  PARAMETERS _ _ 


Parameter 

Value  (hours) 

Description 

DR*  max 

Appropriate 

Value 

Maximum  allowable  downtime  for  component  "X" 
which  will  not  decrease  the  operational  capability  of 
the  system,  and  therefore  will  not  count  as  a  failure 

D.  REALIZATION  OF  THE  IDEALIZED  APPROACH 

The  applicability  of  the  available  closed  form  tools  for  the  modeling  and  evaluating 
of  the  behavior  of  the  complex  modular  structure  of  a  new  and  mostly  unknown  elec¬ 
tronic  weapon  system  within  the  given  three-echelon  maintenance  system  of  the  German 
Army  is  limited  in  three  ways: 


22 


1.  It  is  a  nightmare  to  apply  the  closed  form  tools  for  calculating  the  desired  results 
under  the  assumption  of  Weibull-  or  Gamma-distributed  Times  Between  Failures 

2.  Applying  exponential  failure  rates  will  make  the  closed  form  calculations  much 
easier,  but  too  many  assumptions  have  to  be  made,  unreasonably  simplifying  the 
real  world  environment 

3.  Though  a  closed  form  calculation  could  be  done  by  a  computer  program,  this 
program  will  not  be  flexible  enough  for  applications  with  different  configurations. 

The  only  way  to  proceed  is  the  application  of  an  open  form  method,  the  simulation 
of  the  complex  real  world  situation.  In  simulating  this  situation  it  is  generally  assumed 
that 

•  A  system  is  down  when  one  component  fails,  and  is  up  again  when  this  component 
is  replaced 

•  No  aging  takes  places  during  downtimes 

•  For  each  repaired  component  a  new  time  to  next  failure  starts. 

Using  simulation  we  have  to  decide  on  the  length  of  the  time  period  simulated.  This 
time  period  will  be  split  up  in 

1.  the  phase  used  for  determination  of  the  reliability  of  the  system  (though  we  will  not 
use  it  as  a  decision  criterion) 

2.  a  second  phase  up  to  the  end  of  the  time  period,  which  is  determined  by  war  ana¬ 
lysts  to  reflect  a  realistic  war  scenario  (to  obtain  numerical  values  for  spare  part 
shocks  at  Organizational  and  Intermediate  Maintenance  facilities) 

3.  a  third  phase  up  to  the  end  of  simulation  time,  which  has  to  be  determined  yet  (to 
cover  long-run  aspects) 

For  illustration  purposes  we  will  introduce  a  Sample  System  in  the  next  chapter  (see 
Figure  8  on  page  34).  From  the  (fictitious)  current  ADM  (Acquisition  Decision  Mem¬ 
orandum)  for  this  Sample  System  we  learn  that  the  required  time  period  for  reliability 
considerations  (the  average  system  availability  required  is  90  %)  is  set  to  175  hours,  i.e. 
5  weeks  of  peacetime  or  1  week  of  wartime.  So  the  length  of  the  first  time  phase  will  be 
175  hours. 

Though  the  future  NATO  wartime  scenario  is  about  to  be  redefined  after  the  end 
of  the  cold  war,  the  "historical"  value  of  30  days  of  wartime  is  applied.  So  the  end  of  the 
second  time  phase  will  be  at  720  hours,  resulting  in  a  phase  duration  of  720-175=  545 
hours. 

Special  considerations  are  necessary  to  determine  the  appropriate  total  simulation 
time.  Due  to  the  fact  that  many  components  have  a  MTBF  that  is  decisively  greater  than 
720  hours,  many  of  these  components  wall  not  fail  within  the  first  tw'o  simulation  time 
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phases,  and  might  create  the  impression  that  they  are  not  necessarily  to  be  kept  in  stock. 
Another  drawback  is  the  fact  that  the  Mean  Time  To  First  Failure  (MTTFF)  is  always 
greater  than  the  Mean  Time  Between  Failures  (MTBF),  which  causes  the  average  avail¬ 
ability  and  the  expected  MTBF  to  be  computed  with  higher  values  than  using  a  longer 
time  period.  To  give  each  Subassembly  and  each  Element  the  "chance  to  fail"  within  the 
simulation  horizon,  the  total  simulation  time  period  should  be  chosen  at  a  value  some 
10  times  as  large  as  the  largest  MTBF-value  of  any  Subassembly  or  Element.  With  this 
method  the  computed  availability  of  the  system  also  asymptotically  approaches  the 
steady  state  value,  because  the  initial  MTTFF  is  dominated  by  an  increasing  number  of 
MTBF-values  used. 

Consequently  the  time  horizon  for  our  Sample  System  will  be  15230  hours  (MTBF 
of  Subassembly  A02A  =  1523  hours),  divided  in  a  first  phase  of  175  hours  (to  obtain  a 
reliability  value),  a  second  phase  of  545  hours  (to  obtain  the  necessary  spare  part  stocks 
for  a  war  scenario  of  30  days),  and  a  third  phase  with  the  remaining  14510  hours  (to 
achieve  the  availability  and  the  MTBF-value  of  the  system  in  the  long  run). 
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IV.  DEVELOPED  AND  APPLICABLE  MULTI-ECHELON  MODELS 

A.  EVALUATION  OF  EXISTING  MULTI-ECHELON  MODELS 

Research  among  existing  multi-echelon  simulation  models  used  by  all  branches  of 
the  L'.S.  Armed  Forces  showed  that  these  programs  are  mainly  aimed  at  the  solution  of 
the  following  problems  [Ref.  19): 

•  Tie  budget  dollars  to  readiness.  This  approach  can  not  help  in  our  case,  because 
costs  are  unknown  at  the  respective  point  of  time  in  the  acquisition  process. 

•  Determine  the  inventory  levels  required  at  each  echelon  of  supply  given  a  readiness 
objective.  This  aspect  comes  closer  to  the  problem  to  be  solved,  but  it  is  based  upon 
a  given  number  of  repair  personnel.  While  this  feature  can  help  in  the  second  part 
of  the  problem,  it  does  not  solve  the  essential  problem  of  determining  the  number 
of  repair  personnel  at  each  maintenance  echelon. 

•  Predict  readiness  given  the  inventor}’  level  at  each  echelon  of  supply.  Also  this  feature 
can  not  help  in  our  case,  because  its  basis  are  the  numbers  we  need  from  the  sim¬ 
ulation. 

Generally  it  is  to  be  stated  that  all  models  concentrate  on  the  supply  side  of  the 
multi-echelon  idea.  As  stated  for  the  given  problem  in  II.C.2.e.,  necessary  stock  levels 
are  only  considered  as  far  as  these  stocks  are  located  at  the  respective  maintenance  fa¬ 
cilities.  The  three-echelon  maintenance  system  represented  by  our  stochastic  model  (see 
Figure  6  on  page  20)  is  a  closed  environment,  where  the  only  link  to  the  "outside  world" 
is  the  replacement  parts  stock  for  D-Units  at  Depot  Maintenance. 

One  way  to  proceed  is  the  development  of  a  new  program  that  simulates  the  be¬ 
havior  of  a  weapon  system  with  four  indenture  levels  within  the  military  environment 
of  a  closed  three  echelon  maintenance  system.  But  this  task  is  far  beyond  the  scope  of 
a  master's  thesis.  Another  way  to  approach  the  problem  is  the  application  of  one  of 
these  existing  simulation  programs  under  flexible  use  of  the  offered  features  close  to  the 
problem.  One  simulation  program  that  is  both  applicable  under  this  approach  and 
available  for  use  by  a  foreign  student  at  the  Naval  Postgraduate  School  is  the  "TIGER 
Reliability  Computer  Program",  developed  and  distributed  for  Government  use  by  the 
NAVAL  SEA  SYSTEMS  COMMAND,  Washington  D.C.  [Ref.  20]. 

B.  THE  SIMULATION  PROGRAM  'TIGER" 

TIGER  is  designed  to  calculate  the  mission  performance  parameters  of  ship  system 
reliability  and  availability,  and  concentrates  on  the  efficient  supply  with  spares  within 
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the  Naval  Supply  System  under  consideration  of  available  repair  shop  capacities  and 
failure  characteristics  of  the  used  equipment.  It  is  in  use  in  the  US  Army  and  US  Air 
Force,  too,  and  can  be  applied  stepwise  to  obtain  all  the  data  which  are  needed  to  solve 
the  given  decision  problem. 

For  use  in  this  thesis,  the  program  is  first  introduced  with  the  problem  relevant  input 
and  output  options.  Uater  the  necessary  sequence  of  steps  in  applying  "TIGER”  is  de¬ 
veloped  using  a  sample  system. 

1.  General  Overview 

The  general  objective  of  "TIGER"  is  the  prediction  of  RAM  (Reliability, 
Availability,  Maintainability)  performance  of  a  general  system,  defined  by  data  about 
the  components  within  its  indenture  levels.  "TIGER"  is  an  event  driven  stochastic  sim¬ 
ulator  [Ref.  20,  p.2-5],  and  generates  internally  the  following  component  events: 

1.  Failure  of  a  component 

2.  Arrival  of  a  spare  part  for  a  waiting  component 

3.  Release  of  shop  capacity  for  a  waiting  component 

4.  Repair  of  a  component 

The  special  features  necessary  to  solve  the  given  problem  are  listed  below  [Ref.  20,  p.2-7 
-  2-9],  including  first  remarks  about  their  sometimes  limited  applicability  for  the  given 
problem. 

•  Gamma  distribution  for  failures  and  delays,  and  exponential  distribution  for  repair 
times:  however,  only  integer  /1-values  from  1  to  9  are  possible  (where  /?  =  9  comes 
closest  to  a  Normal  distribution) 

•  Limited  shop  capacities;  these  shop  capacities  are  the  central  decision  parameters; 
however,  the  only  shops  considered  are  one  "General  Shop"  and  up  to  20  specialty 
shops 

•  Allowable  downtime;  because  not  all  components  of-a  weapon  system  are  essential 
for  the  mission  performance,  the  failure  of  certain  components  can  be  tolerated  for 
some  time  without  being  counted  as  system  failure 

•  Group  rules;  using  string  rules  all  grouped  components  are  turned  ofT  while  the 
group  is  down  due  to  failure  of  a  specified  control  component  7,  while  standby  rules 
take  care  of  redundancies 

•  Logistic  models;  offering  both  spares  inventory  policy  and  unlimited  spares 


7  In  order  to  avoid  excessive  simulation  run  times  the  application  of  this  rule  is  only  appro 
priate,  if  M™F, s  jo  (Ref.  jo,  p.  s-2| 

JV1  I  1  J'spgclfitd  control  component 
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2.  The  Input  Formats 

The  input  formats  are  described  in  [Ref.  20,  section  3).  To  get  an  idea  about  the 
input  structure,  the  relevant  input  formats  needed  to  start  a  "TIGER"  simulation  are 
described  below  (the  numbers  indicate  the  respective  TIGER  input  format): 

1.  Distinctive  name  of  simulation  (for  later  identification) 

2.  Number  of  Monte  Carlo  simulations;  optional  individual  integer  random  seed 

3.  Time  horizon  of  simulation;  phase  definitions  for  successive  simulations  under 
changing  conditions  and/or  changing  configurations  (up  to  6  phases  in  one  simu¬ 
lation  run) 

4.  -  blank  - 

5.  Selection  of  printout  option 

6.  -  blank  - 

7.  Multiplier  for  all  MTBF-values  to  model  special  conditions;  multiplier  for  all 
MTTR-values  to  model  special  conditions;  capacity  of  general  shop;  capacity  of 
special  repair  shops 

8.  Component  identification:  user  defined  type  number  (between  1  and  200)  and  name 
for  easier  identification  of  maximal  200  different  component  types;  MTBF;  MTTR 
or  indicator  for  not  repairable  item;  LDTtutf]i\  LDT„0Ck\  probability  that  a  repair  re¬ 
quires  a  part  at  all  (complementary  probability  that  a  failure  can  be  fixed  by  simple 
methods);  Gamma  shape  parameter  for  delay  times;  Gamma  shape  parameter  for 
failures 

9.  -  blank  - 

10.  -  blank  - 

11.  -  blank - 

12.  enumeration  of  all  components  used  in  the  System  (up  to  500  components  of  the 
above  defined  200  different  types);  a  system  in  the  way  "TIGER"  is  used  here  can 
be  a  single  unit  of  the  Weapon  System  with  components  being  Subsystems,  or  can 
be  a  military  command  level  with  components  being  military  units  using  Suni,  units 
of  the  Weapon  System 

13.  -  blank  - 

14.  Indicator  for  unlimited  spares  or  general  number  of  spares  (same  number  for  each 
type  of  spare) 

15.  Individual  number  of  spares  per  component  (overrides  format  14) 

16.  System  definition  (system  in  a  general  sense,  not  as  an  indenture  level  of  an  elec¬ 
tronic  system;  from  now  on  referenced  as  "TIGER  system  definition");  in  contrary 
to  the  known  or  estimated  components  which  are  defined  with  type  numbers  1  to 
500  in  format  8,  in  this  and  the  two  following  formats  the  unknown  System,  the 
Subsystems  and  the  Assemblies  are  defined  with  type  numbers  501  to  1000. 
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17.  Subsystem  definition  (components  building  up  System  defined  in  format  16;  from 
now  on  referenced  as  "TIGER  subsystem  definition);  allowable  downtimes  for 
these  "TIGER  subsystems" 

18.  Group  definition  (components  building  up  the  "TIGER  system"  and  the  "TIGER 
subsystems"  defined  in  format  16  and  17,  which  are  controlled  by  standby-  and 
string  rules  (see  IV.B.l) 

19.  Standby-  and  string  rules 

20.  -  blank  - 

21.  -  blank  - 

3.  The  Output  Formats 

"TIGER"  offers  a  variety  of  output  options.  The  output  formats  are  listed  and 
described  below  as  far  as  they  are  relevant  for  the  given  problem: 

1.  Phase  Figure  of  Merit  Final  Report  (Ref.  20,  p.  10-7]  for  the  entire  system 

a.  Mean  for  reliability  at  the  end  of  each  time  phase 

b.  Mean  for  availability  at  the  end  of  each  time  phase 

2.  Final  Figure  of  Merit  Summary  [Ref  20,  p.  10-7]  for  the  entire  system 

a.  Mean  and  variance  for  reliability  at  the  end  of  the  simulation  time 

b.  Mean  and  variance  for  availability  at  the  end  of  the  simulation  time 

c.  Mean  and  variance  of  the  MTBF  at  the  end  of  the  simulation  time 

d.  Estimate  of  the  long-term  value  of  the  availability 

e.  Estimate  of  the  long-term  value  of  the  MTBF 

3.  Subsystems  Figures  of  Merit  [Ref.  20,  p.  10-7]  for  each  subsystem 

•  Average  Availability  at  the  end  of  each  time  phase 

4.  Component  Performance  Statistics  [Ref  20,  p.  10-12] 

•  Summary'  of  spares  used  at  the  end  of  the  simulation  time 

5.  Critical  Component  List  [Ref.  20,  p.  10-12]. 

•  Contribution  of  each  component  type  to  the  unavailability  of  the  entire  system 
and  each  subsystem 
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V.  THE  DECISION  MODEL 


A.  DECISION  VARIABLES 

As  already  discussed  in  III.C.2  and  shown  in  Table  4  on  page  22,  the  following  de¬ 
cision  variables  have  to  be  handled: 

1.  R2,  the  number  of  repair  personnel  at  Maintenance  Echelon  2  (Organizational 
Maintenance) 

2.  ^(B-Unit),  the  number  of  spare  B-Units  in  stock  at  Maintenance  Echelon  2 

3.  RiD .  the  number  of  repair  personnel  at  Maintenance  Echelon  3  (Intermediate 
Maintenance)  at  Division  level 

4-  P,D  jroc<(B-,C-  or  D-Unit),  the  number  of  spare  B-,  C-  and  D-L'nits  in  stock  at 
Maintenance  Echelon  3  at  Division  level 

5.  R3C,  the  number  of  repair  personnel  at  Maintenance  Echelon  3  (Intermediate 
Maintenance)  at  Corps  level 

6.  P3CjwJr(B-,C-  or  D-Unit),  the  number  of  spare  B-,  C-  and  D-Units  in  stock  at 
Maintenance  Echelon  3  at  Corps  level 

However,  the  way  to  obtain  R3D  and  R3Dstock  is  the  same  as  obtaining  R3C  and  R3Cj„cA 
-  they  differ  only  in  the  number  of  weapon  systems  to  be  supported  by  one  Maintenance 
Batallion.  So  in  the  further  approach,  which  will  develop  the  actual  utilization  of  avail¬ 
able  tools,  we  will  cover  only  R2,  R3,  ^««*(B-Units)  and  P3  ,„C<(B-,  C-  and  D-Units). 

B.  INFLUENCE  DIAGRAM 

Due  to  the  fact  that  there  is  no  directly  applicable  simulation  model  for  the  given 
maintenance  environment,  we  have  to  decide  about  the  necessary  steps  in  using  the 
available  programs.  To  gain  insight  into  the  decision  problem  structure,  we  develop  an 
Influence  Diagram  ,  shown  in  Figure  7  on  page  30. 

1.  Given  Data 

The  only  given  data  at  the  beginning  of  the  decision  process  are 

•  The  (rough)  structure  of  the  new  Weapon  System  with 

■  definition  of  functional  units 

■  level  of  used  technology 
•  redundancy  concept 

•  The  required  Average  System  Availability 
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Figure  7.  Influence  Diagram  for  the  Upcoming  Decision 
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2.  Available  Data 

For  many  already  deployed  systems  the  TBF-  and  TTR-values  for  Subsystems, 
Assemblies,  Subassemblies  and  Elements  are  recorded  and  available.  The  functional 
characteristics  of  these  evaluated  components  are  known,  also  their  technology  level. 
Based  on  the  given  System  Structure  we  can  exploit  similarities  between  components  of 
the  future  system  and  known  components.  However,  this  link  is  not  straightforward,  and 
has  the  character  of  an  assumption. 

3.  Direct  Conclusions 

Based  on  the  used  TTR-  and  TBF-values  for  the  Subassemblies  and  Elements 
of  the  new  system,  and  assuming  unlimited  personnel  and  materiel  resources  at  Organ¬ 
izational  Maintenance,  we  can  obtain  an  Upper  Availability  Limit  for  one  unit  of  the 
new  system.  This  is  a  technology  determined  upper  value,  which  can  not  be  increased 
by  any  organizational  decision  or  any  other  means. 

4.  Decision  Variables 

a.  Personnel  in  Organizational  Maintenance 

Based  on  the  System  Structure,  the  required  Average  System  Availability, 
the  estimated  TBF-values  and  the  Upper  Availability  Limit,  and  under  assumption  of 
unlimited  supply  of  B- Units  at  Organizational  Maintenance,  the  consequences  of  certain 
numbers  of  repair  personnel  at  Organizational  Maintenance  can  be  modeled  and  a  de¬ 
cision  based  on  an  analysis  can  be  made. 

b.  Materiel  in  Organizational  Maintenance 

Based  on  the  available  personnel  at  Organizational  Maintenance  (=  the 
number  decided  upon),  the  estimated  TBF-values  and  the  underlying  war  scenario,  the 
consequences  of  certain  stock  levels  of  B-Units  at  Organizational  Maintenance  can  be 
modeled  and  a  decision  based  on  analysis  can  be  made. 

c.  Personnel  in  Intermediate  Maintenance 

Based  on  the  System  Structure,  the  estimated  TBF-values  and  the  Upper 
Availability  Limit,  and  under  assumption  of  unlimited  supply  of  C-  and  D-Units  at 
Intermediate  Maintenance,  the  consequences  of  certain  numbers  of  repair  personnel  at 
Intermediate  Maintenance  can  be  modeled  and  a  decision  based  on  an  analysis  can  be 
made. 

d.  Materiel  in  Intermediate  Maintenance 

Based  on  the  available  personnel  at  Intermediate  Maintenance  (■  the 
number  decided  upon),  the  estimated  TBF-values  and  the  underlying  war  scenario,  the 
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consequences  of  certain  stock  levels  of  B-,  C-  and  D-Units  at  Intermediate  Maintenance 
can  be  modeled  and  a  decision  based  on  analysis  can  be  made. 

5.  Final  Conclusion 

Based  on  the  personnel  and  materiel  quantities  at  Organizational  Maintenance, 
and  under  assumption  of  sufficient  personnel  and  materiel  quantities  at  Intermediate 
Maintenance  ( =  the  numbers  decided  upon),  the  Maximum  Achievable  Average  System 
Availability  under  the  quantified  Maintenance  System  can  be  checked  versus  the  Upper 
Availability  Limit. 
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VI.  SIMULATION  WITH  THE  TIGER  PROGRAM 


At  first  the  preparative  structuring  of  the  new  Weapon  System  for  the  input  process 
is  described,  followed  by  the  essential  input  steps  for  each  successive  simulation  run.  The 
applicability  of  the  respective  results  for  our  decision  problem  is  shown,  and  the  rea¬ 
soning  for  the  next  input  step  is  derived. 

A.  PREPARATIVE  STRUCTURING  OF  THE  WEAPON  SYSTEM 

To  simplify  the  illustration  of  the  use  of  "TIGER"  in  solving  the  given  problem,  and 
to  show  the  emerging  results  and  their  consequences,  the  program  is  applied  to  the 
simple  yet  complete  Sample  System  configuration  shown  in  Figure  8  on  page  34. 

In  contrast  to  the  "TIGER"  concept  only  very  few  components  (if  any  at  all)  shown 
in  our  Sample  System  configuration  have  known  TBF  and  TTR.  Proceeding  down  from 
the  System  level,  and  skipping  the  Subsystem  level,  all  Assemblies  are  checked  for  avail¬ 
able  MTBF-data,  /?-values  for  the  distribution  of  the  TBF  and  MTTR-data: 

1.  If  there  are  no  real  data  available  for  an  Assembly,  we  proceed  further  down  and 
check  the  Subassemblies  and  those  Elements  which  are  not  a  direct  part  of  a  Sub- 
assembly.  Elements  within  a  Subassembly  are  only  handled  by  depot  level  mainte¬ 
nance,  which  is  not  covered  here  (see  I.D.3) 

a.  If  we  have  real  data  for  a  Subassembly  or  an  Element,  which  might  be  in  use  in 
an  already  deployed  weapon  system,  these  data  are  applied 

b.  If  there  are  no  real  data  available,  data  from  a  component  with  similar  functional 
characteristics  and  a  comparable  level  of  technology  are  applied 

c.  In  case  of  several  similar  components  with  different  parameters  or  in  case  of 
components  with  a  totally  new'  conceptual  design,  the  best  possible  estimates  8 
have  to  be  applied 

2.  If  w'e  have  real  data  from  an  Assembly,  w'hich  is  in  use  in  an  already  deployed 
weapon  system,  the  Assembly  itself  is  treated  as  an  unknown,  but  with  exactly  one 
known  Subassembly 

3.  As  a  further  preparation  for  the  input  the  known  or  estimated  Subassemblies  and 
Elements  are  assigned  a  type  number  between  I  and  500,  all  unknown  Subsystems 
and  Assemblies  a  number  between  501  and  1000.  One  possible  choice  for  assigning 
these  numbers  is  shown  in  Figure  8  on  page  34. 

At  the  end  of  this  process  each  branch  of  the  configuration  tree  ends  with  a  com¬ 
ponent  for  which  the  MTBF,  /?  and  MTTR  data  are  fixed.  Because  we  do  not  have  any 


8  Again,  the  user  has  to  be  experienced  in  his  functional  specialty 
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Subassemblies  (XXXA  etc.)  and  Elements  (XXX01  etc.)  !  C03A  IjJ 


11 

MTBF  =  1327,  6  =  3 
A01A  MTTR  =  4.1 

13 

MTBF  =  841,  6  =  9 
A02A  MTTR  =  3.6 

15 

MTBF  =  344,  6  =  9 
A03  MTTR  =  1.5 

12 

MTBF  =  644,  6  =  9 
A01B  MTTR  =  3  9 

14 

MTBF  =  1523,  6  =  9 
A0201  no  repair 

known  assembly 

21 

MTBF  =  225,  6=1 

25 

MTBF  =  866.  6  =  7 

2  redundant 

B0101  no  repair 

B0201  no  repair 

assemblies  23 

(24) 

MTBF  =  534,  6  =  9 
B0102  no  repair 

26 

MTBF=  1167,  6  =  5 
B02A  MTTR  =  13  8 

31 

MTBF  =  544,  6  =  9 
C0101  no  repair 

33 

MTBF  =  1322,  6  =  9 
C02A  MTTR  =  3.8 

35 

(36) 

MTBF  =  210,  6  =  9 
C03A  MTTR  =  8  4 

32 

MTBF  =  732,  6  =  7 
C0102  no  repair 

34 

MTBF  =  1003,6  =  4 
C02B  MTTR  =9  5 

(37) 

3  redundant 
subassemblies 

41 

MTBF  =  375,  6  =  5 
D01A  MTTR  =  1.5 

44 

MTBF  =  554,  6  =  5 
DO 2 A  MTTR  =  7  2 

46 

MTBF  =  628,  6  =  2 
D03  MTTR  =  2.3 

42 

MTBF  =445,  6  =  9 
D01B  MTTR  =  4  1 

45 

MTBF  j=  1303,  6  =  3 
D0201  no  repair 

known  assembly 

43 

MTBF  =  1127,  6  =  8 
D01C  MTTR  =  22.6 

Figure  8.  Sample  System  Configuration  (Prepared  for  Input) 


34 


information  about  interdependencies  between  components  at  this  stage  of  the  develop¬ 
ment  process,  we  assume  that  there  are  none  at  the  moment.  Components  with  stand-by 
redundancies  (groups  of  components,  where  in  case  of  failure  of  the  active  component 
another  component  starts  operating)  are  grouped  using  the  TIGER  stand-by  rule;  gen¬ 
erally  string  rules  will  not  be  applied,  because  for  electronic  equipment  with  high  reli¬ 
abilities  and  short  repair  times  the  MTBF/MTTR-quotient  (see  footnote  7  on  page  26) 
will  mostly  be  considerably  higher  than  50. 

B.  MAXIMUM  AVERAGE  WEAPON  SYSTEM  AVAILABILITY 

The  input  file  for  the  first  simulation  step  lists  all  Subassemblies  and  Elements  with 
their  (known  or  estimated)  individual  MTBF-  and  0-x, alues  to  determine  the  failure 
characteristics  of  the  entire  (unknown)  system.  Each  failure  of  any  component  initializes 
the  repair  of  the  failed  A-Unit  (Subsystem)  by  replacing  the  failed  B-Unit  (Assembly 
within  the  failed  A-Unit).  This  repair  time  can  be  assumed  to  be  relatively  constant  due 
to  the  technology  used  (BITE  etc.,  see  Table  1  and  Table  3,  MARTa).  Starting  with  the 
general  maintenance  system,  i.e.  without  applying  any  exceptional  regulations,  we  will 
obtain  the  maximum  achievable  availability  under  ideal  conditions  by  assuming  both 
unlimited  shop  capacity  and  unlimited  supply  of  spare  B-Units  at  Organizational  Main¬ 
tenance.  Because,  at  this  point  of  time,  we  do  not  need  any  information  about  spare 
parts  used,  we  do  not  need  to  record  the  results  of  the  second  time  phase  (see  III.D.). 

To  gain  more  insight  into  the  Maintenance  of  the  new  Weapon  System,  we  addi¬ 
tionally  consider  2  methods  for  increasing  the  numerical  value  of  the  maximum  possible 
average  system  availability: 

•  Relaxed  Tactical  Requirements.  The  Mission  Need  Statements  (MNS),  which  ini¬ 
tialize  the  acquisition  process  for  a  new  weapon  system,  tend  to  require  an  avail¬ 
ability  of  a  weapon  system  close  to  100%  with  no  allowable  downtimes  for  any 
Subsystem.  In  many  projects  this  goal  can  not  be  achieved  even  under  the  ideal 
approach  described  above.  Therefore  allowable  downtimes  for  selected  Subsystems 
are  additionally  entered.  It  is  essential  to  point  out,  that  the  quality  of  the  weapon 
system  is  not  improved  at  all  by  this  means  -  it  is  just  a  statistical  improvement  aimed 
at  the  purpose  of  the  decision  aid  ! 

•  Exceptional  Spare  Stock  of  A-Units  (Subsystems)  at  location  of  Organizational 
Maintenance.  Now  an  unlimited  spare  stock  of  A-Units  at  the  organizational  level 
is  allowed,  actually  reducing  the  mean  delay  time  until  resuming  operation. 

1.  Step  1,  Run  1  -  System  in  the  General  Maintenance  System 

For  the  first  step  one  unit  of  the  Weapon  System  is  defined  in  a  format  16 
statement  ("TIGER  system  definition"),  and  all  Assemblies,  Subassemblies  and  Elements 
are  assigned  to  their  respective  Subsystem  under  format  17  ("TIGER  subsystem  defi- 
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nition").  Strictly  following  the  rules  (see  II.D.l.  -  no  spare  stock  of  A-Units  at  the  or¬ 
ganizational  level),  the  resulting  mean  delay  time  until  resuming  operation  is 
MARTa  +  LDTStliek  +  ADT2  =  5,  given  the  required  B-Unit  is  available  at  the  re¬ 
placement  parts  stock  of  the  Organizational  Maintenance.  Due  to  the  "fixed"  repair  time 
of  5  hours  this  value  is  entered  as  "real  organizational  delay",  while  the  MTTR-values 
for  all  Subassemblies  and  Elements  are  set  to  0.001  (Tiger  default  value).  This  method 
is  necessary  to  neglect  any  repair  times  for  these  components,  which  are  irrelevant  in  this 
first  step.  Without  regarding  any  eventually  allowable  downtimes,  the  results  of  the  first 
simulation  run  offer  a  set  of  data  based  on  the  technology  used  and  on  the  unmodified 
general  maintenance  system.  Any  possible  real-world  logistic  delays  could  not  happen 
due  to  assumption. 

The  following  results  are  determined  from  the  first  run: 

•  Upper  limit  for  Average  System  Availability  under  consideration  of  technology  and 
general  maintenance  system.  Without  any  exceptional  regulations  within  the  general 
maintenance  system  no  higher  value  for  the  average  availability  can  be  achieved. 

•  MTBF  for  one  unit  of  the  System  under  the  conditions  stated  above 

•  As  additional  information  we  obtain  the  Reliability  for  the  time  period  entered  as 
first  phase  duration.  But  as  pointed  out  above  (see  III.B.4.),  reliability  can  not  be 
used  as  a  criterion  for  the  upcoming  decision,  and  therefore  will  be  tracked  only 
occasionally. 

The  relevant  results  for  our  Sample  System  (for  this  and  the  next  three  runs)  are 
listed  in  Table  6  on  page  38. 

2.  Step  1,  Run  2  -  System  under  Relaxed  Tactical  Requirements 

In  many  projects  the  desired  availability  can  not  be  achieved  even  under  the 
ideal  approach  modeled  in  Run  1.  Therefore  the  second  run  additionally  regards  allow¬ 
able  downtimes  for  selected  Subsystems  under  tactical  considerations. 

The  results  of  the  second  run  offer: 

•  Tactically  Increased  Upper  Limit  for  Average  System  Availability  .  By  allowing 
downtimes  for  not-operationally-essential  Subsystems,  the  technology  determined 
upper  limit  for  the  average  availability  of  each  unit  of  the  Weapon  System  will  be 
increased  once  more,  offering  insight  into  the  consequences  of  tight  requirements. 

•  MTBF  for  one  unit  of  the  System  under  the  conditions  stated  above 

The  MTBF-value  should  be  decisively  higher  than  that  in  Run  I  (less  failures 
counted  for  calculation  of  down  time). 
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3.  Step  1,  Run  3  -  System  in  Modified  Maintenance  System 

For  the  third  run  one  unit  of  the  Weapon  System  is  defined  in  the  same  way  as 
in  Step  1.  But  now  an  unlimited  spare  stock  of  A-Units  at  the  organizational  level  is  al¬ 
lowed,  reducing  the  mean  delay  time  until  resuming  operation  to 
LDT„0Ck  +  ADT2  =  3.  This  value  is  now  entered  as  "real  organizational  delay",  while 
the  MTTR- values  are  kept  at  0.001.  Assuming  unlimited  shop  capacity  and  no  allowable 
downtimes  again,  an  ideal  (modified)  logistic  environment  is  modeled  -  the  results  of  the 
third  run  offer  a  set  of  data  based  on  the  technology  used  and  represent  the  maximum 
achievable  average  availability  of  the  planned  Weapon  System  in  the  three  echelon 
maintenance  system  under  exceptional  regulations. 

The  following  results  are  offered  from  the  third  run: 

•  Technology  determined  absolute  upper  limit  for  Average  System  Availability.  With 
no  organizational  or  any  other  means  can  any  higher  value  for  the  average  avail¬ 
ability  be  achieved  within  the  given  maintenance  system. 

•  MTBF  for  one  unit  of  the  System  under  the  conditions  stated  above  (should  be  close 
to  the  MTBF-value  obtained  from  Step  1,  Run  1  -  differences  due  to  simulation) 

4.  Step  1,  Run  4  -  System  Behavior  under  Both  Methods 

As  described  for  Step  1,  Run  2,  additionally  allowable  downtimes  for  selected 
Subsystems  under  tactical  considerations  are  entered.  The  results  of  the  fourth  run  offer: 

•  Tactically  increased  absolute  upper  limit  for  Average  System  Availability 

•  MTBF  for  one  unit  of  the  System  under  the  conditions  stated  above  (should  be  close 
to  the  MTBF-value  obtained  from  Step  1,  Run  2  -  differences  due  to  simulation) 

5.  Evaluation  of  Step  1 

The  requirements  and  the  relevant  results  from  Step  1  for  the  given  Sample 
System  are  summarized  in  Table  6  on  page  38. 

The  standard  deviation  for  all  A  -values  obtained  by  simulation  is  0.000,  point¬ 
ing  out  that  at  t=  15230  we  obviously  have  reached  a  steady  state.  Dependent  on  the 
required  availability  and  the  results,  some  options  for  the  further  approach  might  no 
longer  be  reasonable.  In  our  example,  no  stock  of  A-Units  at  the  location  of  the  Or¬ 
ganizational  Maintenance  has  to  be  considered,  because  the  required  availability  of  90 
%  can  be  achieved  under  the  allowable-downtime  approach?. 

9  These  results  also  offer  insight  into  the  consequences  of  too  tight  tactical  requirements,  which 
might  drive  up  costs  if  accepted  without  analysis 
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Table  6.  MAXIMUM  ACHIEVABLE  SYSTEM  AVAILABILITY 


iiillllt  Jjj  jmi 

MTBF 

R 

MTTFF 

Requirement 

A  =  0.900 

No  stock  of  A-Units,  no  allowable 
downtimes 

43.6 

0.696 

227.2 

No  stock  of  A-Units,  relaxed  require¬ 
ments 

wmm 

72.3 

0.924 

299.2 

Unlimited  stock,  no  allowable  down¬ 
times 

43.8 

0.700 

214.0 

Unlimited  stock,  relaxed  requirements 

A  =  0.960 

72.6 

0.928 

292.3 

So  the  further  approach  uses  the  environment  modeled  in  Run  2.  The  input  file 
for  Run  2  is  shown  completely  in  Appendix  A,  and  the  resulting  output  for  Step  1,  Run 
2  is  shown  partially  (without  computer  system  messages,  input  echo  and  an  error  mes¬ 
sage^)  in  Appendix  B. 

C.  PERSONNEL  QUANTITIES  AT  ORGANIZATIONAL  MAINTENANCE 

Still  under  the  assumption  of  an  unlimited  stock  of  B-Units,  the  unlimited  repair 
capacity  at  Organizational  Maintenance  will  be  reduced  now  to  realistic  values.  To 
model  this  situation,  a  new  approach  is  needed,  using  MTBF- values  of  all  Subsystems, 
and  regarding  the  entire  military  user  unit.  We  do  not  need  information  about  spare 
parts  used  nor  about  the  reliability  of  the  subsystems.  Therefore  we  do  not  record  the 
results  of  the  first  two  time  phases. 

1.  Step  2,  Run  1  -  MTBF-Values  for  Subsystems 

To  obtain  these  MTBF-values,  each  Subsystem  is  defined  in  a  format  16  state¬ 
ment  ("TIGER  system  definition")  and  as  only  Subsystem  under  format  17  ("TIGER 
subsystem  definition"),  while  all  its  Subassemblies  and  Elements  are  assigned  to  this  one 
Subsystem.  The  environment  for  these  simulation  steps  assumes  no  stock  of  A-Units  at 
Organizational  Maintenance,  and  no  allowable  downtimes  are  entered  to  obtain  the 
technology  determined  MTBF.  The  repair  shop  capacity  is  without  influence  on  the  re- 

10  TIGER  calculates  the  reliability  for  t=  15230  a s  R<  16_4S  and  causes  a  'Floating  Point 
Underflow  Exception';  using  'Standard  Corrective  Action',  the  value  of  R  is  set  to  0.000,  and  the 
program  completes  correctly 
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suit  of  Run  1,  and  is  kept  unlimited.  One  run  for  each  Subsystem  has  to  be  performed. 
The  following  result  is  offered  from  the  first  run: 

•  Technology  determined  MTBF-V’alues  of  all  Subsystems 

Due  to  the  characteristics  of  the  TIGER  simulation  these  values  are  offered 
without  any  distribution  parameters.  In  order  to  avoid  unrealistic  simplification  by  using 
the  mean  values  only,  the  generally  accepted  assumption  of  exponential  distribution  for 
time  between  failure  (see  III.A.l)  will  be  used  for  further  computations. 

For  our  Sample  System  the  following  results  are  obtained: 


Table  7.  MTBF-VALUES  FOR  SUBSYSTEMS 


Subsystem 

MTBF 

&  simulcvcn 

A 

A 

145.7 

6.513 

0.966 

B 

471.3 

6.470 

0.990 

C 

206.0 

7.035 

0.976 

D 

110.3 

6.073 

0.956 

Entire  System 

72.30 

6.150 

0.934 

2.  Step  2,  Run  2  -  Minimum  Personnel  Quantity,  Unlimited  Stock 

Starting  with  personnel  quantity  of  1  (the  minimum  value  -  see  II.D.l),  we  de¬ 
fine  the  military  unit  in  format  16  ("TIGER  system  definition"),  consisting  of  Sumt  sets 
of  all  Subsystems.  For  our  Sample  System  we  learn  from  the  (assumed)  ADM  that  each 
military  unit  has  Suni,  =  17  units  of  the  Weapon  System.  The  MTTR  is  2  hours  (see 
Table  3);  the  stock  of  B-Units  is  unlimited;  the  delay  time  is  LDT„0Ch  +  ADT2  =  3 
hours.  Due  to  the  characteristics  of  TIGER  the  "allowable  downtime"  approach  is  not 
applicable  in  this  data  input  configuration  -  allowable  downtimes  can  be  entered  only  for 
"TIGER  subsystems"  (here  the  17  weapon  systems).  That  means  for  our  Sample  System 
that  the  maximum  achievable  Average  System  Availability  will  be  0.892  (subject  to  de¬ 
viations  due  to  simulation)  instead  of  0.934,  which  has  to  be  considered  in  evaluating  the 
output  and  deciding  upon  the  personnel  quantity. 

Because  we  are  primarily  not  interested  in  the  "TIGER  system"  availability  (the 
"availability"  of  one  military  unit),  but  in  the  availability  of  each  unit  of  the  Weapon 
System  (the  "TIGER  subsystem"  availability),  the  output  option  for  subsystems  has  to 
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be  chosen.  Nevertheless,  defining  the  military  unit  as  available  (combat  ready)  if  15  out 
of  17  weapon  systems  are  up,  we  will  have  a  glance  at  this  value. 

The  following  result  is  offered  from  the  second  Run: 

•  Lpper  limit  for  Average  System  Availability  at  minimum  personnel  quantity  at  Or¬ 
ganizational  Maintenance 

3.  Step  2,  Run  3  -  Increased  Personnel  Quantity,  Unlimited  Stock 

If  the  resulting  upper  limit  for  the  Average  System  Availability  is  insufficient, 
further  runs  with  incremented  personnel  quantities  (up  to  a  realistic  limit)  have  to  be 
performed,  eventually  resulting  in  the 

•  Upper  limit  for  Average  System  Availability  for  personnel  quantity  of  2  at  Organiza¬ 
tional  Maintenance 

•  Upper  limit  for  Average  System  Availability  for  personnel  quantity  of  3  at  Organiza¬ 
tional  Maintenance 

•  ... 

•  ... 

•  Upper  limit  for  Average  System  Availability  at  maximum  personnel  quantity  at  Or¬ 
ganizational  Maintenance.  For  our  Sample  System  the  maximum  realistic  personnel 
quantity  is  assumed  to  be  4. 

For  our  Sample  System  the  resulting  upper  limits  for  the  Average  System 
Availability  for  one  unit  of  the  Weapon  System  with  a  given  personnel  quantity  and  an 
unlimited  stock  of  B-Units  at  the  location  of  the  Organizational  Maintenance  are  shown 
in  Table  8. 


Table  8.  PERSONNEL  AT  ORGANIZATIONAL  MAINTENANCE 


Quantity  of  Per¬ 
sonnel 

Maximum  Average  System  Avail¬ 
ability 

Availability  of  the  Mili¬ 
tary  Unit 

1  ( =  minimum) 

1 1,1 

0.453 

2 

p  =  0.888,  o  =  0.0005 

0.706 

3 

0.731 

4  ( =  maximum) 

ft  =  0.894,  a  =  0.0005 

0.731 

Threshold 

0.892 

— 
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4.  Evaluation  of  Step  2 

As  a  general  rule  the  smallest  value  for  the  personnel  quantity,  which  provides 
the  desired  numerical  availability  valueii,  will  be  used  for  all  further  computations. 
However,  the  data  base  used  for  these  calculations  is  not  exact  at  all  -  most  values  are 
(and  will  be  in  later  applications)  very  rough  estimates.  So  it  is  the  responsibility  of  the 
experienced  user,  to  decide  about  the  appropriate  personnel  quantity.  In  our  case  quan¬ 
tity  1  provides  an  Average  System  Availability  of  0.813  versus  the  maximum  availability 
of  0.892  (equivalent  to  91.1  %),  quantity  2  provides  0.888  (equivalent  to  99.6  %),  and 
quantity  3  even  offers  0.893,  which  can  be  considered  as  being  the  maximum  value 
(again,  deviations  caused  by  simulation).  For  our  Sample  System,  quantity  2  will  be  used 
further  on. 

If  even  the  realistic  maximum  number  of  repair  personnel  is  insufficient  to 
achieve  the  desired  numerical  availability,  the  introduction  of  an  exceptional  stock  of 
A-Units  at  Organizational  Maintenance  might  be  regarded  by  repeating  Step  2  not  based 
on  Step  1,  Run  2,  but  on  Step  1,  Run  3  or  4. 

If  under  the  assumption  of  an  unlimited  stock  of  B-Units  a  certain  personnel 
quantity  is  sufficient,  this  quantity  can  be  looked  upon  as  the  maximum  quantity  nec¬ 
essary.  But  this  personnel  can  not  utilize  an  unlimited  stock.  Consequently  the  unlimited 
stock  of  B-Units  at  Organizational  Maintenance  should  now  be  reduced  to  realistic  val¬ 
ues,  applying  the  personnel  quantity  obtained  in  Step  2. 

D.  MATERIEL  QUANTITIES  AT  ORGANIZATIONAL  MAINTENANCE 

As  pointed  out  in  II.C.2.e.,  stock  levels  will  only  be  considered  as  far  as  they  are 
located  at  the  facilities  of  the  respective  Maintenance  Echelon.  So  now  we  need  to  know 
how  many  units  of  each  B-L'nit  should  be  held  at  each  location  of  Organizational 
Maintenance.  The  main  reason  for  keeping  this  stock  at  all  is  the  chance  to  increase  the 
Achievable  Average  System  Availability  during  combat.  The  second  time  phase  (as  de¬ 
fined  in  III.D.)  becomes  relevant  now,  and  due  to  the  output  characteristics  of  TIGER 
(summary'  of  spares  used  at  the  end  of  the  simulation  time  -  see  IV.B.3.4)  the  simulation 
time  horizon  is  now  reduced  to  720  hours. 


1 1  See  the  discussion  about  the  application  of  the  'allowable  downtimes"  idea  for  this  simu¬ 
lation  step  in  VI. C.  2. 
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1.  Step  3,  Run  1  -  Maximum  Number  of  Spare  Parts  Used  in  War  Scenario 

Applying  the  personnel  quantity  obtained  by  Step  2,  Run  2  or  3,  we  simply  re¬ 
peat  the  respective  simulation  run  with  decreased  time  horizon.  The  "unlimited  spares" 
option  is  kept  in  the  input  file  to  prevent  any  supply  from  outside.  The  result  of  this 
repeated  run  will  be  the 

•  Upper  Limit  for  Spare  Parts  needed  at  Organizational  Maintenance  in  the  Applied 
War  Scenario 

If  every  failure  results  in  the  replacement  of  the  respective  B-Unit  by  personnel 
of  Organizational  Maintenance,  this  is  the  maximum  number  of  spare  parts  needed 
during  the  war  scenario.  By  setting  the  "spares  allowance"  for  each  Assembly  individ¬ 
ually  to  the  smallest  integer  being  greater  than  the  computed  values,  wrhile  still  assuming 
unlimited  supply  at  the  intermediate  level  DES,  we  will  obtain  from  Step  3,  Run  1  the 
Maximum  Average  System  Availability  achievable  with  this  stock  level.  Because  some 
parts  will  now  be  used  out  of  the  Intermediate  Maintenance  DES  -  some  simulation  runs 
need  more  than  the  average  number  of  spare  parts  -  we  additionally  enter 
LDTdes  =  10  hours,  the  delay  time  to  obtain  spare  parts  from  the  DES. 

2.  Step  3,  Run  2  -  Consequences  of  Lower  Allowances 

With  the  above  values  being  upper  limits,  we  want  to  analyze  the  consequences 
of  lower  allowances  now.  The  only  drawback  of  lower  stock  levels  is  the  increased  lo¬ 
gistic  delay  time  due  to  supply  out  of  the  DES  of  the  respective  Maintenance  Batallion. 
Instead  of  checking  each  combination  of  decreased  allowances,  we  set  all  allowances  at 
Organizational  Maintenance  to  Zero,  and  keep  the  stock  level  at  the  Intermediate 
Maintenance  DES  unlimited,  thus  obtaining  the 

•  Upper  Limit  for  Spare  Parts  needed  at  the  Intermediate  Maintenance  DES  in  the 
Applied  War  Scenario 

•  Upper  Limit  for  the  Achievable  Average  System  Availability  with  Zero  Stock  Allow¬ 
ance  at  Organizational  Maintenance 

3.  Step  3,  Run  3  -  Consequences  of  Zero  Stock  Allowances 

In  economically  tough  times  even  the  necessity  of  any  stock  levels  outside  the 
military  supply  line  might  be  in  doubt.  To  be  able  to  present  data  for  this  situation,  we 
finally  set  both  the  stock  level  at  Organizational  Maintenance  and  at  the  Intermediate 
Maintenance  DES  to  Zero  (setting  the  DES  to  Zero  with  stock  of  Organizational 
Maintenance  at  upper  limit  will  not  change  the  results  from  Run  1,  because  only  an 
average  of  3  or  4  Assemblies  will  be  used  from  the  DES).  Repeating  Run  2,  but  replacing 
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the  10  hour  delay  (for  receiving  the  needed  Assembly  from  the  respective  DES)  by  a  35 

hours  delay  (for  the  use  of  the  military  supply  line),  we  obtain 

•  Upper  Limit  for  the  Achievable  Average  System  Availability  with  Zero  Stock  Allow¬ 
ance 

The  results  of  Step  3,  Run  1  to  3  are  summarized  in  Table  9. 


Table  9.  MATERIAL  AT  ORGANIZATIONAL  MAINTENANCE 


Modeled 
Stock  Lev- 
els(0  = 

Org  Maint, 

I  =  Interm 
Maint) 

Allowance  at 
Org  Maint 
(Assembly 
A/B/C/D) 

Allowance 

at 

IntermMaint 
DES  (As¬ 
sembly 
A/B/C/D) 

Maximum 

Average 

System 

Availabil¬ 

ity 

B- Units 
obtained 
from  Inter¬ 
mediate 
Mainte¬ 
nance  DES 
(Assembly 
A/B/C/D) 

B- Units 
obtained 
from  Sup¬ 
ply  line 
(Assembly 
A/B/C/D) 

Upper 
Limit  at  O, 
unlimited 
DES  at  I 

101/32/73, 134 

unlimited 

0.885 

4,3/3/ 3 

0/00/0 

Zero  at  O, 
unlimited 
DES  at  I 

0,00/0 

unlimited 

m 

97/32/70/125 

0/ 0/0/0 

Zero  at  O, 
Zero  DES 
at  I,  unlim¬ 
ited  supply 

0  0/0/0 

0/0  0/0 

m 

0/0/0/0 

84/30/63/104 

Threshold 

- 

- 

0.888 

- 

- 

4.  Evaluation  of  Step  3 

All  calculations  in  Step  3  have  been  performed  under  the  assumption  that 
available  stocks  are  not  refilled  during  the  time  period  set  by  the  applied  war  scenario. 
Nevertheless  unlimited  supply  of  spare  parts  at  the  respective  source  was  used  in  the 
simulation  runs.  While  this  method  was  used  in  Run  1  and  2  just  as  a  tool  to  obtain  the 
maximum  stock  levels  at  Organizational  Maintenance  and  the  Intermediate  Mainte¬ 
nance  DES,  the  use  of  the  unlimited  supply  line  (see  assumption  stated  in  II.C.2.e.)  was 
realized  in  Run  3  and  4  to  model  the  situation  of  Zero  allowances. 

Evaluating  the  data  displayed  in  Table  9,  consequences  of  cuts  proposed  in 
budgetary  discussions  can  be  demonstrated  based  on  analysis  rather  than  on  pure  and 
not  necessarily  wrong,  but  improvable  intuition.  Pertaining  to  numerical  numbers  for 
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optimal  stock  levels  at  Organizational  Maintenance  and  Intermediate  Maintenance  DES, 
we  need  more  information  about  the  back  flow  of  repaired  components,  which  are  used 
to  refill  both  the  stock  at  Organizational  Maintenance  and  the  DES  at  Intermediate 
Maintenance  during  the  simulated  time  period. 

E.  QUANTITIES  AT  INTERMEDIATE  MAINTENANCE 

Entering  the  intermediate  level,  the  environment  is  similar  to  that  modeled  for  the 
organizational  level;  however,  the  objects  for  repair  are  now  Assemblies  (B-Units).  These 
B-Units  fail  as  described  above,  are  replaced  by  the  Organizational  Maintenance,  and 
finally  arrive  some  time  after  failure  at  the  Intermediate  Maintenance.  TIGER  does  not 
offer  any  links  between  Organizational  and  Intermediate  Maintenance;  so  we  can  not 
simulate  the  exact  arrival  times.  But  we  can  model  this  delay  time  by  modeling  the  ar¬ 
rival  at  Intermediate  Maintenance  at  the  time  of  failure,  and  covering  the  delay  time  by 
ADT,  +  LD rw(Organiz.)  +  LDTS, M*(Intermed.)  -I-  ADT2  =  39,  the  number  of  hours 
caused  by  administrative  and  logistic  delay  per  repair  job  in  Maintenance  Echelon  3  (see 
Table  3  on  page  21)  plus  the  delay  time  occurred  in  Organizational  Maintenance  while 
replacing  the  defective  B-Unit.  Under  the  assumption  of  an  unlimited  stock  of  C-  and 
D-Units,  we  first  have  to  obtain  the  MTBF-values  of  all  Assemblies,  and  then  have  to 
model  all  subordinate  military7  units  served  by  the  Maintenance  Batallion.  For  our 
Sample  System  we  learn  from  the  (fictitious)  ADM,  that  each  Corps  will  have  three  Di¬ 
visions  using  the  new  Weapon  System,  and  that  each  Division  will  have  3  Brigades,  each 
commanding  2  Military'  Units  supplied  with  17  Weapon  Systems  each.  Referring  to 
Table  2  on  page  12,  each  Maintenance  Batallion  at  the  Division  level  will  service  102 
Units  of  the  Weapon  Systems. 

1.  Step  4,  Run  1  -  MTBF-Values  for  Assemblies 

To  obtain  these  MTBF-values,  each  Assembly  is  defined  in  a  format  16  state¬ 
ment  ("TIGER  system  definition")  and  as  only  component  under  format  17  ("TIGER 
subsystem  definition"),  while  all  its  Subassemblies  and  Elements  are  assigned  to  this  one 
Assembly.  No  downtimes  are  applied,  and  any  repair  shop  capacity  is  kept  unlimited. 
One  run  for  each  Assembly  has  to  be  performed.  The  following  result  is  offered  from  the 
first  run: 

•  Technology  determined  MTBF-  Values  of  all  Assemblies 

As  discussed  in  VI.C.l.,  the  generally  accepted  assumption  of  exponential  dis¬ 
tribution  for  time  between  failure  will  be  used  for  further  computations. 

The  results  for  our  Sample  System  are  shown  in  Table  10  on  page  45. 
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Table  10.  MTBF- VALUES  FOR  ASSEMBLIES 


2.  Step  4,  Run  2  -  Minimum  Personnel  Quantity,  Unlimited  Stock 
a.  Approach  as  Proved  in  Step  2 

So  far  the  new  Weapon  System  could  be  treated  without  regarding  different 
fields  of  technology.  MTBF-values  are  computationally  independent  from  the  used 
technology,  and  the  personnel  at  Organizational  Maintenance  could  be  planned  across 
the  fields  of  technology  due  to  the  way  they  are  supposed  to  perform:  localize  defective 
LRU  by  using  BITE  or  straightforward  traditional  techniques,  and  replace  them.  At 
Intermediate  Maintenance  however,  personnel  for  all  different  fields  of  technology  have 
to  be  available.  To  show  the  modeling  of  this  situation,  we  assume  that  our  new  Weapon 
System  is  made  up  of  four  different  fields  of  technology,  resulting  in  the  use  of  4  "TI¬ 
GER  specialty  shops". 
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We  stan  with  personnel  quantity  of  2  (the  minimum  value  -  see  lI.C.2.b.), 
defining  the  Division  in  format  16  ("TIGER  system  definition"),  consisting  of  UD  Sun„  sets 
of  the  number  of  Assemblies  used  per  System.  Each  Assembly  is  defined  by  its  Subas¬ 
semblies  and  Elements,  and  the  MTTR  for  each  Assembly  is  determined  by  the  used 
technology  (see  III.B.2.  and  Table  3  on  page  21).  The  stock  of  C-  and  D-Units  is  as¬ 
sumed  to  be  unlimited. 

For  our  Sample  System  UDSuni,  =  102,  resulting  in  1224  "TIGER  subsys¬ 
tems";  the  (assumed)  MTTR  for  the  different  technologies  are  7  (Subsystem  A),  4  (Sub¬ 
system  B),  12  (Subsystem  C)  and  3  (Subsystem  D).  The  delay  time  is  39  hours. 
b.  Dimensional  Problems 

At  this  point  we  are  about  to  run  into  dimensional  trouble  with  TIGER. 
Table  11  compares  the  dimensional  needs  to  perform  Step  2,  Run  2  (Personnel  at  Or¬ 
ganizational  Maintenance)  and  Step  4,  Run  2  (Personnel  at  Intermediate  Maintenance) 
with  the  capacity  of  TIGER. 


Table  1 1.  DIMENSIONAL  PROBLEMS  WITH  "TIGER" 


Data 

Capacity- 
needed 
(Step  2) 

Capacity 
needed 
(Step  4) 

Capacity 

offered 

Number  of  distinct  Subsystems 

17 

1224 

31 

Number  of  Component  types 

20 

20 

200 

Number  of  distinct  Components 

68 

2040 

500 

First  of  all,  I  want  to  emphasize  that  this  is  not  the  fault  of  the  TIGER  pro¬ 
gram  !.  As  pointed  out  in  IV.A.,  Tiger  is  one  of  the  available  simulation  programs,  and 
in  this  application  it  has  not  been  used  in  the  way  it  was  designed.  It  is  moreover  a  sign 
of  the  versatility  of  TIGER  that  it  could  be  used  so  far  in  such  a  successful  way.  But 
we  will  run  into  trouble  even  earlier,  if  we  want  to  model  electronic  material  of  the 
combat  troops.  As  discussed  in  II.C.l.,  combat  units  have  a  large  number  of  identical 
equipment.  If  we  try,  for  example,  to  obtain  data  for  the  maintenance  concept  for  the 
electronic  components  of  a  battle  tank  -  in  general  an  Armored  Batallion  has  52  battle 
tanks  (52  TIGER  subsystems  in  Step  2  versus  the  capacity  of  31  subsystems)  -,  we  can 
not  use  the  described  approach. 
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c.  Goal  to  be  achieved  by  Intermediate  Maintenance 

Another  problem  arises  in  defining  the  optimality  criterion  for  Step  A,  Run 
2.  In  Step  2  the  goal  to  be  achieved  was  clearly  defined:  keep  the  Average  System 
Availability  at  or  above  the  numerical  value  required  by  the  ADM  !  We  could  use  this 
criterion  if  TIGER  would  offer  the  feature  of  refilling  any  stocks  with  components  re¬ 
paired  within  the  Maintenance  System.  Due  to  the  origin  of  TIGER  in  the  Navy,  the 
general  shop  (and  eventually  involved  special  shops)  repair  the  Weapon  System  as  a 
whole  under  the  environment  of  a  Three  Echelon  Supply  System.  There  is  no  repair  of 
defective  components  performed  to  refill  stock  levels  -  TIGER  does  not  model  a  Three 
Echelon  Maintenance  System  ! 

Though  even  if  we  would  be  able  to  handle  the  dimensional  problem,  this 
missing  link  will  make  it  impossible  to  proceed  further  on  with  the  use  of  TIGER. 
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VII.  FURTHER  APPROACH  USING  MODSIM 


Being  unable  to  complete  our  decision  aid  with  TIGER,  we  now  attack  the  problem 
with  the  same  approach,  but  applying  the  simulation  language  MODSIM  II,  which 
came  to  my  knowledge  only  in  the  last  Quarter  at  NPS.  As  far  as  this  Thesis  is  con¬ 
cerned,  only  initial  feasibility  checks  are  performed.  The  development  of  a  complete 
simulation  program  has  to  be  done  by  follow-on  research. 

A.  REDUCED  STOCHASTIC  MODEL 

Applying  the  TIGER  simulation  program  (see  VI.),  we  have  realized  that  all  data 
necessary  to  solve  the  given  problem  can  be  obtained  without  modeling  the  entire 
stochastic  model  shown  in  Figure  6  on  page  20.  Thus  we  will  use  a  reduced  stochastic 
model  for  the  remaining  parts  of  the  problem  (shown  in  Figure  9  on  page  49). 

The  only  parts  of  the  initial  stochastic  model  to  be  considered  are: 

1 .  Structured  Weapon  System  with  its 

a.  Subsystems 

b.  Assemblies 

c.  Subassemblies 

d.  Elements 

2.  Organizational  Maintenance  with  its 

a.  Waiting  Queue 

b.  Repair  Capacity 

c.  Stock  of  B-Units  for  replacement 

3.  Intermediate  Maintenance  with  its 

a.  Waiting  Queue 

b.  Repair  Capacity 

c.  Direct  Exchange  Stock 

d.  Stock  of  C-  and  D-Units  for  replacement  (assumably  unlimited  ) 

The  sequence  of  steps  will  be  the  same  as  with  TIGER,  as  this  approach  has  been 
proved  to  be  adequate  and  successful.  Upon  final  development  of  the  problem  specific 
MODSIM  simulation  program,  the  results  for  our  Sample  System  obtained  by  TIGER 
can  be  cross  checked  with  the  values  obtained  by  MODSIM. 
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Figure  9.  Reduced  Stochastic  Model 


B.  MODSIM  II  -  GENERAL  OVERVIEW 

MODSIM-II  is  a  general-purpose,  procedural  programming  language  [Ref.  21].  It 
is  an  object-oriented  language,  and  it  performs  discrete-event  simulation.  Like  in  real 
world,  each  object  has 

•  Attributes  (fields  with  information  about  the  object  like  MTBF  for  a  component, 
number  of  repair  men  for  a  maintenance  facility,  or  allowances  for  stocks) 

•  Behaviors  (methods  the  object  can  perform  like  failing  of  a  component,  starting  a 
repair  by  a  repairman,  or  the  fact  that  a  stock  is  decreased  by  taking  out  a  com¬ 
ponent). 

Fields  within  an  object  can  only  be  changed  by  a  method  of  this  object.  Methods 
can  be 

•  ASK  methods,  where  the  object  is  asked  by  another  object  to  perform  a  procedure, 
and  where  the  other  object  waits  until  this  procedure  is  finished  in  order  to  get 
certain  field  values  back.  However,  no  simulation  time  elapses  during  the  waiting 
period. 

•  TELL  methods,  where  the  object  is  told  by  another  object  to  invoke  a  procedure, 
which  is  performed  independently  from  the  "telling"  object.  No  waiting  and  no  re¬ 
turning  of  values  takes  place. 

Each  TELL-method  can 

•  Elapse  simulation  time  during  performance 

•  Wait  for  start  of  performance  until  being  told  or  until  a  fixed  point  in  (simulation) 
time 

•  Send  messages  (ASK/TELL)  to  other  objects  during  and  after  completion. 

Objects  can  be  created  dynamically.  Fields  and  methods  of  objects  can  be  inherited 
to  other  objects,  or  can  be  kept  private.  Many  objects  with  the  same  behavior  can  be 
used,  distinguished  by  name  only  (e.g.  in  our  sample  system  306  Subsystems  of  type  A, 
306  Subsystems  of  type  B  etc.).,  but  also  objects  with  unique  behavior  (e.g.  the  one  Di¬ 
rect  Exchange  Stock  at  Intermediate  Maintenance).  Some  built-in  objects  and  built-in 
procedures  (used  as  a  built-in  method  if  encapsulated  in  an  object)  can  be  utilized  (see 
[Ref.  21],  Appendices  D  and  E).  Table  12  on  page  51  gives  an  overview  about  the  ob¬ 
jects  necessary  to  model  our  reduced  stochastic  model,  and  indicates  the  dimensional 
ranges  for  each  object  pertaining  to  our  Sample  System. 
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Table  12.  NECESSARY  MODSIM  OBJECTS 


Name(s) 

Description 

Number  necessary 
for  the  introduced 
Sample  System 

Built-in 

CompXXXX 

Component-Object,  defining  the 
properties  of  each  Subassembly, 
Assembly  and  Subsystem. 

102  x  (12  +  4)  = 
1632 

No 

ElemXXXX 

Element-Object,  defining  the 
properties  of  each  Element 

102  x  20  =  2040 

No 

SystemXXX 

System-Object,  defining  the 
properties  of  each  unit  of  the 
Weapon  System 

102 

No 

MaintXX 

Maintenance-Object,  defining  a 
maintenance  facility 

17  +  1  =  18 

No 

QueueXX 

Queue-Object,  defining  a  "Wait¬ 
ing  for  Maintenance"-queue 
(FIFO)  at  a  maintenance  facility 

17  +  1  =  18 

QueueObj 

RepairXX 

Repair-Ohject  defining  the  repair 
capacity  of  one  repair  person  at 
a  maintenance  facility 

1 7x(  1  '2;  3,4)  + 
(2/3/4/...)  = 
(17/.../68)  +  (2/...) 

No 

StockXX 

Stock-object,  defining  stock  levels 
at  a  maintenance  facility 

(17  x  12)  +  12  = 
216 

Not  with 
the  fea¬ 
tures  re¬ 
quired 

C.  DEVELOPMENT  OF  MODSIM-II  MODULES 

MODSI.M-II  programs  can  be  divided  into  different  "modules",  each  stored  in  a 
separate  file.  Each  module  can  be  compiled  separately,  saving  both  time  and  resources 
when  minor  changes  have  to  be  made.  While  the  main  program  (acting  like  the  super¬ 
visor  of  the  simulation)  is  stored  in  one  module  called  MAIN  MODULE,  many  com¬ 
monly  used  variables  and  types  can  be  stored  in  one  or  several  DEFINITION 
MODULES.  Commonly  used  procedures  additionally  need  to  be  coded  in  an  accompa¬ 
nying  IMPLEMENTATION  MODULE.  Each  Object  can  also  be  defined  and  coded  in 
a  separate  pair  of  DEFINITION  MODULE  and  IMPLEMENTATION  MODULE. 
To  begin  a  MODSIM  simulation,  the  best  approach  is  the  definition  of  all  variables  and 
types,  that  are  used  in  several  objects,  in  an  initial  DEFINITION  MODULE  "Global", 
followed  by  the  definition  and  implementation  of  all  necessary  objects  with  their  attri¬ 
butes  and  the  methods  they  can  perform. 


51 


1.  Global  Variables  and  Types 

This  is  the  place  to  define  all  fixed  parameters  listed  in  Table  3  on  page  21. 
Pertaining  to  the  variable  parameters  listed  in  Table  4  on  page  22,  we  can  define  the 
parameters  R2,  Rir>  and  R1C,  which  will  be  controlled  by  the  future  user  to  obtain  the  re¬ 
spective  value  for  the  decision  criterion,  the  Achievable  Average  System  Availability  (see 
also  VI. C.),  and  DTXmn,  which  will  be  known  (or  simply  set  to  zero)  at  the  begin  of  the 
decision  process. 

In  the  Type  Declaration  the  known  but  fixed  values  for  different  object  fields 
are  set.  As  an  example,  the  field  "Status",  defined  in  Component-Object,  is  limited  to  the 
values  "operating",  "pausing",  "broken"  and  "standby".  Declaring  this  Type  in  "Global" 
ensures  that  no  other  value  for  "Status"  can  be  introduced  anywhere  else,  and  avoids  the 
explicit  declaration  in  each  object. 

The  DEFINITION  MODULE  "Global"  is  shown  in  Appendix  C. 

2.  Objects  of  Weapon  System 

We  will  begin  the  definition  of  objects  with  those  needed  to  model  the  weapon 
system.  The  most  general  module  is  the  Component-Object,  having  all  fields  and  meth¬ 
ods  most  parts  of  a  technical  system  have  as  main  characteristics.  This  Component- 
Object  has  the  fields 

•  Name  -  the  identifier  of  the  defined  component 

•  IndentLevel  -  indicates  the  indenture  level  of  the  respective  component  (Subsystem, 
Assembly,  Subassembly  or  Element) 

•  Technology  -  indicates  main  field  of  electronic  technology  used  in  the  defined  com¬ 
ponent 

•  MasterComponent  -  name  of  component  in  next  higher  indenture  level  the  defined 
component  is  part  of 

•  Tenants  -  name  of  components  in  next  lower  indenture  level  which  reside  inside  the 
object  (if  any) 

•  Status  -  indicates  if  object  is  operating,  pausing,  broken  or  in  stand-by 

•  BrokenParts  -  names  of  those  components  at  each  indenture  level  that  are  broken 
and  need  to  be  replaced  at  the  appropriate  maintenance  facility 

•  StandBy Avail  -  indicates  if  there  is  a  ready-to-start  stand-by-component  available 

and  is  able  to  perform  the  following  methods: 

•  ASK  METHOD  Break  -  component  is  informed  about  an  occurred  failure  within 
its  tenants,  breaks  and  passes  message  and  names  of  broken  parts  on  to  its  master 
component 
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•  ASK  METHOD  Pause  -  each  component  is  informed  about  an  occurred  failure 
within  its  Weapon  System,  and  pauses  in  its  aging  process  until  its  Weapon  System 
is  in  operating  status  again 

•  TELL  METHOD  UpAgain  -  each  component  is  told  to  resume  operational  status 
again 

The  Element-Object  inherits  all  fields  and  methods  of  Component-Object.  It  has 
four  additional  fields 

•  mean  -  Mean  Time  Between  Failure 

•  alpha  -  shape  parameter  a  for  Gamma  distribution  of  time  between  failures 

•  TimeToFailure  -  period  in  simulation  time  until  component  fails  next  time 

•  Discard  -  indicator  for  irreparable  component 

and  two  additional  methods. 

•  TELL  METHOD  ComputeNextFail  -  the  value  for  field  TimeToFailure  is  com¬ 
puted 

•  ASK  METHOD  Fail  -  element  is  told  to  fail,  and  passes  message  and  its  own  name 
upwards  to  its  master  component 

The  System-Object  inherits  all  fields  of  Component-Object,  and  has  four  addi¬ 
tional  fields 

•  StartDownTime  -  records  the  point  in  time  at  which  system  failed 

•  SumOfDownTimes  -  adds  (SimulationTime  -  StartDownTime)  to 
SumOfDownTimes  at  that  point  in  time  at  which  system  returns  to  operational 
status 

•  AverageAvailability  -  keeps  track  of  the  average  availability  value  for  its  weapon 
system  in  the  simulation 

•  MilitaryUnit  -  name  of  military  unit  to  which  the  system  belongs, 
has  one  additional  method 

•  ASK  METHOD  DownTime  -  system  is  asked  to  report  SumOfDownTimes 

and  one  method  overriding  the  method  with  the  same  name  in  Component-Object: 

•  ASK  METHOD  Break  (OVERRIDE)  -  system  is  informed  about  an  occurred 
internal  failure  and  orders  all  of  its  still  operable  tenants  to  pause  in  the  aging 
process 

These  three  objects  are  defined  and  implemented  in  the  module 
"WeaponSystem".  The  "DEFINITION  MODULE  WeaponSystem"  and  the  "IMPLE¬ 
MENTATION  MODULE  WeaponSystem"  are  both  shown  in  Appendix  D. 
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3.  Objects  of  Maintenance  System 

After  the  definition  of  the  objects  needed  to  model  the  weapon  system,  now  the 
objects  needed  to  model  the  maintenance  system  are  defined.  The  Organizational- 
Maintenance-Object  has  the  fields 

•  Name  -  the  identifier  of  the  defined  Organizational  Maintenance  Facility 

•  NumberRepairObj  -  the  number  of  Repair-Objects  within  the  Maintenance  Facility 

•  IdleRepairFacilities  -  the  number  of  idle  Repair-Objects  at  a  point  in  time 

•  IdleFacility  -  the  idle  Repair-Object  which  will  be  assigned  a  job  next 

•  Stock  -  the  list  of  stock  levels  for  all  available  spare  parts 

•  JobQueue  -  the  "waiting  for  maintenance"-queue 

•  ComponentToReplace  -  the  component  which  will  be  assigned  next  to  an  idle 
Repair-Object 

•  ResponsiblelntMaintFac  -  the  name  of  the  next  higher  Intermediate  Maintenance 
Facility 

and  is  able  to  perform  the  following  methods: 

•  ASK  METHOD  OrgQueueJob  -  adds  a  failed  Subsystem  to  the  "waiting  for 
maintenance"-queue  of  an  Organizational  Maintenance  Facility 

•  ASK  METHOD  ReportOfldle  -  object  is  informed  about  a  Repair-Object  having 
become  idle 

•  TELL  METHOD  Assign  -  assigns  a  repair  job  to  the  asking  Repair-Object 

•  ASK  METHOD  SendToRepair  -  object  is  informed  that  a  replaced  Subsystem  has 
to  be  sent  to  the  respective  Intermediate  Maintenance  Facility 

The  Intermediate-Maintenance-Object  inherits  all  fields  and  methods  of 
Organizational- Maintenance-Object.  It  has  one  additional  method 

•  ASK  METHOD  IntQueueJob  -  adds  a  failed  Component  to  the  "waiting  for 
maintenance"-queue  of  an  Intermediate  Maintenance  Facility 

and  one  method  overriding  the  method  with  the  same  name  in  Organizational- 
Maintenance-Object: 

•  TELL  METHOD  Assign  -  assigns  a  repair  job  to  the  asking  Repair-Object,  too, 
but  applies  different  administrative  and  logistic  delay  times 

These  two  objects  are  defined  and  implemented  in  the  module  "Maintenance". 
The  "DEFINITION  MODULE  Maintenance"  and  the  "IMPLEMENTATION  MOD¬ 
ULE  Maintenance"  are  both  shown  in  Appendix  E. 
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The  Repair-Object  is  defined  independently  from  the  Maintenance-Object,  and 
has  the  following  fields: 

•  Name  -  the  identifier  of  the  defined  Repair-Object 

•  MaintUnit  -  the  Maintenance-Object  the  Repair-Object  belongs  to 

•  MaintLevel  -  Maintenance  Echelon  at  which  jobs  are  performed  at  this  Repair- 
Object 

•  Qual  -  indicates  qualification  of  Repair-Object  for  certain  fields  of  electronic  tech¬ 
nology. 

Furthermore,  Repair-Object  has  one  method: 

•  TELL  METHOD  Fix  -  object  is  told  to  perform  repair 

For  the  Queue-Object,  which  will  line  up  and  release  maintenance  jobs  following 
the  First-In-First-Out  (FIFO)  policy,  the  built-in  QueueObj  can  be  utilized. 

The  Stock-Object  just  has  to  keep  track  of  the  number  of  a  certain  component 
in  stock  and  of  the  number  of  eventual  reorders  that  can  not  be  satisfied  upon  occur¬ 
rence.  It  does  not  ha'.e  to  follow  any  policy  like  FIFO  or  LIFO.  It  fields  are 

•  NameOfComp  -  name  of  respective  Component-Object 

•  NameOfMaintObj  -  name  of  Maintenance-Object  where  Stock-Object  is  located 

•  Allowance  -  maximum  number  of  components  in  stock 

•  Level  -  number  of  components  actually  in  stock  at  a  point  in  time 

•  MaxReOrder  -  maximum  number  of  reorders  occurring  during  simulation  run, 

and  its  methods  are 

•  ASK  METHOD  OffStock  -  decreases  actual  stock  level  by  one 

•  ASK  METHOD  ToStock  -  increases  actual  stock  level  by  one 

•  ASK  METHOD  TrackReOrder  -  keeps  track  of  the  reorders. 
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VIII.  EVALUATION  AND  SUMMARY 


A.  PURPOSE  OF  THE  DECISION  AID 

As  stated  in  Chapter  I,  the  main  purpose  of  the  decision  aid  to  be  developed  is  ob¬ 
taining  reasonable  and,  as  far  as  achievable  at  the  relevant  point  of  time  within  the 
Weapon  Acquisition  Process,  reliable  numbers  for  personal  and  material  quantities, 
which  have  to  be  entered  into  the  respective  Acquisition  Decision  Memoranda  (ADM). 

B.  GENERAL  SHORTCOME  OF  THE  DECISION  AID 

Though  this  decision  aid  tries  to  model  reality  as  close  as  possible,  its  results  are 
only  as  good  as  the  quality  of  the  input  data  -  a  characteristic  known  as  "garbage  in, 
garbage  out".  Due  to  the  origin  of  the  MTBF-data  for  all  involved  Components,  the  aid 
can  not  offer  absolutely  reliable  results.  To  avoid  poor  results  and  a  feeling  of  dissatis¬ 
faction  on  the  user's  side,  utmost  effort  has  to  be  concentrated  in  the  building  of  the  data 
base  for  MTBF-  and  MTTR-values  (see  also  VIII.E.l.b.). 

C.  ACHIEVEMENT  BY  TIGER 

Exploiting  the  multiple  features  of  an  introduced  simulation  program  like  TIGER, 
and  intelligently  varying  the  structure  of  the  input  data,  an  experienced  user  can  obtain 
the  following  numbers  without  any  modifications  to  the  code  of  the  program  (see 
Chapter  VI): 

•  Upper  limit  for  Average  System  Availability  under  consideration  of  technology  and 
general  maintenance  system 

•  Tactically  increased  upper  limit  for  Average  System  Availability 

•  Technology  determined  absolute  upper  limit  for  Average  System  Availability 

•  Tactically  increased  technology  determined  absolute  upper  limit  for  Average  System 
A  vailability 

•  MTBF-values  for  one  unit  of  the  System  under  each  of  the  conditions  stated  above 

•  Technology  determined  MTBF-Values  of  all  Subsystems 

•  Upper  limit  for  Average  System  Availability  at  minimum  personnel  quantity  at  Or¬ 
ganizational  Maintenance 

•  Upper  limit  for  Average  System  Availability  for  personnel  quantity  of  2  and  more  at 
Organizational  Maintenance 

•  Upper  limit  for  Average  System  Availability  at  maximum  personnel  quantity  at  Or¬ 
ganizational  Maintenance 
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•  Upper  Limit  for  Spare  Parts  needed  at  Organizational  Maintenance  in  the  Applied 
War  Scenario 

•  Upper  Limit  for  Spare  Parts  needed  at  the  Intermediate  Maintenance  DES  in  the 
Applied  War  Scenario 

•  Upper  Limit  for  the  Achievable  Average  System  Availability  with  Zero  Stock  Allow¬ 
ance  at  Organizational  Maintenance 

•  Upper  Limit  for  the  Achievable  Average  System  Availability  with  Zero  Stock  Allow¬ 
ance  at  all 

•  Technology  determined  MTBF-Values  of  all  Assemblies 

D.  PROBLEMS  UNDER  TIGER 

As  shown  in  Chapter  VI,  this  approach  is  usable  and  successful  for  new  Electronic 
Weapon  Systems,  as  long  as  the  following  limitations  are  applicable: 

1.  Weapon  System  will  be  repaired  only  in  Maintenance  Echelon  2  (Organizational 
Maintenance) 

2.  The  maximum  number  of  Weapon  System  Units  within  the  responsibility  of  one 
Organizational  Maintenance  Facility  does  not  exceed  31. 

These  limitations  are  met  by  many  Weapon  Systems  to  be  deployed  in  the  combat 
support  and  communication  forces.  They  are  definitely  exceeded  by  specific  material  in 
the  combat  support  and  communication  forces,  and  by  most  electronic  material  de¬ 
ployed  within  the  combat  forces  (see  II.C.l.). 

The  other  limitations  shown  in  Table  11  on  page  46  (maximum  number  of  Com¬ 
ponent  types  =  200,  maximum  number  of  distinct  Components  =  500)  generally  will 
not  impose  any  problem,  because  only  the  rough  design  structure  of  the  new  system  is 
known  at  the  point  in  time  this  decision  aid  will  be  applied.  If  the  information  available 
exceeds  these  limits,  the  project  will  have  proceeded  in  the  acquisition  process,  and  other 
tools  12  will  be  applicable  and  more  appropriate. 

E.  NECESSARY  FUTURE  DEVELOPMENTS 

To  cover  all  kind  of  weapon  systems  the  full  scale  development  of  the  indicated 
MODSIM-II-program  is  inevitable.  Three  major  tasks  have  to  be  performed. 


12  like  Logistic  Support  Analysis  (LSA)  [Ref.  1] 


57 


1.  Development  of  Data  Base 

a.  Weapon  System  Data 

These  data  are  no  problem,  they  can  be  obtained  from  the  existing  design 

papers. 

b.  Component  Data 

The  most  work  intensive  task  (see  VIII. B.)  will  be  the  development  of  the 
data  base  for  MTBF-  and  MTTR-data  for  components  defined  by  their  functional 
characteristics.  The  evaluation  of  data  for  deployed  weapon  systems  can  not  be  per¬ 
formed  on  a  routine  basis;  it  requires  experienced  personnel  with  both  a  background  in 
engineering  science,  the  weapon  acquisition  process,  and  in  the  actual  maintenance 
process  at  the  different  military  maintenance  facilities.  As  a  rough  estimate,  at  least  one 
man-year  is  necessary  to  build  this  data  base,  and  a  continuing  maintenance  is  manda¬ 
tory. 

c.  Deployment  Data 

These  data  are  no  problem,  they  can  be  obtained  from  the  Mission  Need 
Statement  (MNS)  or  an  already  existing  ADM. 

d.  Maintenance  System  Data 

The  fixed  parameters  shown  in  Table  3  on  page  21  are  a  reasonable,  but 
arbitrary  estimate  of  the  real  world  situation.  In  case  of  insufficient  other  information 
they  can  be  applied  without  causing  major  deviations.  A  thorough  evaluation  of  existing 
data  might  offer  more  exact  data,  which  might  be  used  to  randomize  the  different  delay 
times  in  order  to  introduce  even  more  realism  into  the  model.  As  a  rough  estimate,  three 
man-months  are  necessary  to  build  this  part  of  the  data  base,  and  a  continuing  mainte¬ 
nance  is  advisable. 

e.  Limitations  in  Personal  and  Material  Quantities 

These  limitations  are  not  easily  obtained,  because  all  personnel  involved  will 
try  to  hide  eventually  existing  realistic  values  for  reasons  beyond  a  pure  technical  point 
of  view.  Like  the  differentiation  of  component  features  based  on  the  manufacturing 
contractor  (see  III.B.3.),  irrational  behavior  has  to  be  taken  into  account,  once  more 
pointing  to  the  need  for  experienced  users. 

2.  Development  of  a  Semi- Automated  Decision  Aid 

The  procedure  shown  in  Chapter  VI  in  the  application  of  TIGER  was  a  step- 
by-step  off-line  process.  Each  simulation  run  had  to  be  initiated  by  the  user,  though  the 
sequence  of  input  steps  was  predetermined.  Interactions  between  the  user  and  an  on-line 
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simulation  program  are  only  necessary  at  the  following  points  (Step  numbers  and  Run 
numbers  refer  to  Chapter  VI): 

•  After  completion  of  Run  1  to  determine  the  need  for  the  relaxation  of  tactical  re¬ 
quirements  and/or  the  need  for  an  exceptional  spare  stock  of  A-Units  at  the  lo¬ 
cation  of  the  Organizational  Maintenance 

•  After  completion  of  Run  2  to  determine  the  number  of  repair  personnel  at  Organ¬ 
izational  Maintenance  sufficient  to  achieve  the  required  Average  System  Avail¬ 
ability 

•  After  completion  of  a  newly  designed  Run  3.  Run  3  will  offer  combinations  of  pos¬ 
sible  numbers  of  spare  parts  in  stock  at  Organizational  Maintenance  (B-Units)  and 
in  stock  at  Intermediate  Maintenance  -  both  in  the  Direct  Exchange  Stock  (DES, 
B-Units)  and  in  the  general  stock  (C-  and  D-Units)  -  ,  necessary  to  offer  the  Or¬ 
ganizational  Maintenance  "unlimited-like"  supply.  The  user  has  to  determine  those 
combinations  that  seem  to  be  realistic,  and  has  to  start  a  newly  designed  Run  4, 
which  finally  will  offer  the  number  of  repair  personnel  at  Intermediate  Mainte¬ 
nance,  necessary  to  refill  the  stock  levels,  decided  upon  after  Run  3. 

So  the  program  to  be  developed  in  MODSIM  can  be  structured  as  a  four-step 
program,  asking  for  a  decision  by  the  user  after  each  step.  So  no  decision  -  while  using 
the  decision  aid  -  is  made  by  the  program.  The  program  only  assists  the  user  with  data 
based  on  an  analysis,  so  eventually  gaining  acceptance  even  from  decision  makers  who 
might  feel  uncomfortable  with  the  idea  that  their  intuitive  ideas  can  be  performed  by  a 
computer. 

3.  Integration  of  Specific  Features 

The  scope  of  subtleties  that  can  be  integrated  into  the  final  decision  aid  is  nearly 
infinite.  A  trade-off  between  reality  and  applicability  has  to  be  made  in  order  to  prevent 
excessive  run  times  or  ridiculous  results. 

Just  a  few  specialties  seem  to  be  reasonable.  Though  this  listing  can  not  be  final, 
the  following  features  (partially  also  included  in  the  TIGER  program)  should  be  in¬ 
cluded  in  any  further  development: 

•  Allowable  Downtimes  -  this  feature  should  be  available  both  on  the  Subsystem-  and 
the  Assembly-level 

•  Stand-By  -  this  feature  should  be  available  on  all  indenture  levels 

•  Availability  of  Military  Unit  -  enlarging  the  scope  of  availability  data  might  increase 
the  acceptance  also  in  the  military  combat  community 

•  Additional  consideration  of  fractional  personnel  -  without  entering  the  discussion 
about  the  realization  of  a  0.4-person  this  feature  offers  invaluable  information 
about  the  possibility  to  combine  two  "fractional"  repair  persons  for  2  different 
small  systems  with  comparable  technology  to  one  "allround-repair-person"  for  both 
systems. 
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APPENDIX  A.  SAMPLE  INPUT  FILE  FOR  "TIGER" 


This  appendix  contains  the  second  input  file  for  the  TIGER  Reliability  Computer 
Program  (Step  1,  Run  2).  The  reasoning  for  this  input  file  is  described  in  detail  in  IV.B.2. 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 
250  1. 28  1 

1  175.  1  15055. 

51000000000000001 


11SUBASSEMBLY_A01A 

1327. 

5. 

3 

12SUBASSEMBLY_A01B 

664. 

5. 

9 

13SUBASSEMBLY_A02A 

841. 

5. 

9 

14ELEMENT_A0201 

1523. 

5. 

9 

15ASSEMBLY_A03 

344. 

5. 

9 

2 IE  LEMENT_B  0101 

225. 

5. 

1 

23ELEMENT_B0102 

534. 

5. 

9 

25ELEMENT_B0201 

866. 

5. 

7 

26SUBASSEMBLY_B02A 

1167. 

5. 

5 

31ELEMENT_C0101 

544. 

5. 

9 

32ELEMENT.C0102 

732. 

5. 

7 

33SUBASSEMBLY_C02A 

1322. 

5. 

9 

34SUBASSEMBLY_C02B 

1003. 

5. 

4 

35SUBASSEMBLY_C03A 

210. 

5. 

9 

41SUBASSEMBLY_D01A 

375. 

5. 

5 

42SUBASSEMBLY_D0 IB 

445. 

5. 

9 

43SUBASSEMBLY_D0 1C 

1127. 

5. 

8 

44SUBASSEMBLY_D02A 

554. 

5. 

5 

45ELEMENT_D0201 

1303 

5. 

3 

46ASSEMBLY_D03 

628. 

5. 

2 

60 


11 

11 

12 

12 

13 

13 

14 

14 

15 

15 

21 

21 

22 

23 

23 

24 

25 

25 

26 

26 

31 

31 

32 

32 

33 

33 

34 

34 

35 

35 

36 

37 

41 

41 

42 

42 

43 

43 

44 

44 

45 

45 

46 

46 

UNLIMITED 

SPARES 

SYS1 

1 

4 

999 

SUBSYSTEM. 

.A 

501 

0.  0 

SUBSYSTEM. 

_B 

601 

0.  0 

SUBSYSTEM. 

_C 

701 

0.  0 

SUBSYSTEM. 

_D 

801 

35.  0 

2 

510 

11 

12 

2 

520 

13 

14 

1 

530 

15 

3 

501  510 

520 

530 

2 

611 

21 

23 

2 

612 

22 

24 

1 

610 

611 

612 

612 

611 

2 

620 

25 

26 

2 

601 

610 

620 

2 

710 

31 

32 

2 

720 

33 

34 

1 

730 

35 

36 

37 

36 

35 

37 

35 

37 

36 

3 

701 

710 

720 

730 

3 

810 

41 

42 

43 

2 

820 

44 

45 

1 

830 

46 

3 

801 

810 

820 

830 

4  999  501  601  701  801 


*  *  *  End  of  Input -File  *  *  * 


APPENDIX  B.  'TIGER"-OUTPUT  FOR  SAMPLE  INPUT  FILE 


This  appendix  contains  the  output  for  the  sample  input  file  shown  in  Appendix  A. 
The  evaluation  of  this  output  is  described  in  detail  in  IV.B.2. 


*******************t' 

****************************************  *****-.',-********************  *********** 

****  TIGER  SIMULATION  FOR  RELIABILITY,  MAINTAINABILITY,  AND  AVAILABILITY  **** 
***************************************************************************** 


******************************************************* 


V** 


RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 


4-4-H-4-4-4-H-4  f-H-H-H-H-  TIGER  8.  20  tlMHIIIHH  l-H-H-l  I 
4  +  4-44  NAVSEA  05MR  WASHINGTON,  DC  20362-5101  +++++4 
I  MM  I  tilt  14  Ml  4  4  (202)  692-2150  +++-4444  44  4-H-+-H  44  4 


INTIGER 


.  (INPUT  ECHO) 

INPUT  DATA  HIGH  VALUES 


DURATION 

TYPES 

GROUPS 

EQUIPS 

PH-SEQ 

PH-TYP  TRIALS 

15230. 00 

46 

999 

46 

2 

1  250 

OUTTIGER 

PAGE 

0.  924 
0.  998 
175. 000 

0.  984 


RELIABILITY  FOR  PHASE 

1,  1 

0.  924 

RELIABILITY  THRU  PHASE 

1 

AVERAGE  AVAILABILITY 

AVG.  AVAIL.  THRU  PHASE 

”'l 

FOR  PHASE 

1,  1 

0.  998 

TIME  (END  OF  PHASE) 

INSTANT  AVAILABILITY 

INSTANT  AVAILABILITY 

AT  BEGINNING 

OF  PHASE 

1.  000 

AT  END  OF 

PHASE 
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RELIABILITY  FOR  PHASE 

1,  2 

0.  000 

RELIABILITY  THRU  PHASE 

1  0. 000 

AVERAGE  AVAILABILITY 

AVG.  AVAIL.  THRU  PHASE 

1  0. 934 

FOR  PHASE 

1,  2 

0.  933 

TIME  (END  OF  PHASE) 

15230. 000 

INSTANT  AVAILABILITY 

INSTANT  AVAILABILITY 

AT  BEGINNING 

OF  PHASE 

0.  984 

AT  END  OF 

PHASE  0.  920 

FINAL  SUMMARY  STATS 

PAGE 

SYSTEM  FIGURES  OF  MERIT  AFTER 


250  MISSION  TRIALS 

MEAN 

STANDARD  DEVIATION 

OF  THE  SAMPLE  MEAN 

AT  END  OF  MISSION: 

RELIABILITY 

0.  000 

0.  000 

RELIABILITY  LOWER  PRECISION  LIMIT 

(BASED  ON  STANDARD  DEVIATION  CRITERIA) 

0.  000 

INSTANTANEOUS  AVAILABILITY 

0.  920 

0.  017 

AVERAGE  AVAILABILITY 

0.  934 

0.  000 

ESTIMATES  OF  LONG-TERM  VALUES: 

MEAN  TIME  BETWEEN  FAILURES 

72.  3 

MEAN  TIME  TO  REPAIR 

5.  1 

AVAILABILITY 

0.  934 

MISSION  PERFORMANCE  (FAILURE  &  REPAIR  INFORMATION 

CALCULATED  FROM  TIGER  SIMULATION  DATA): 

MEAN  UP  TIME 

72.  3 

6.  150 

MEAN  DOWN  TIME 

5.  1 

6.  150 

MEAN  REPAIR  TIME 

5.  1 

0.  004 

MEAN  ACTIVE  REPAIR  TIME 

0.  0 

0.  000 

MEAN  TIME  TO  FIRST  FAILURE 

299.  2 

5.  744 

TOTAL  NO.  OF  SYSTEM  FAILURES  =  49152 
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TABLE  FAILURES  NUM 


PAGE 


EQUIP  FAILURE  SUMMARY  BY  EQUIPMENT  NUMBER 

EQUIP.  NO.  TYPE  NO.  TOTAL  EQUIP.  AVG.  NO.  FAILURES 

FAILURES  PER  MISSION 


11 

11 

2783 

11.  132 

12 

12 

5586 

22. 344 

13 

13 

4430 

17. 720 

14 

14 

2381 

9.  524 

15 

15 

10792 

43. 168 

21 

21 

16497 

65. 988 

22 

21 

516 

2.  064 

23 

23 

6900 

27.  600 

24 

23 

85 

0.  340 

25 

25 

4291 

17. 164 

26 

26 

3122 

12. 488 

31 

31 

6870 

27. 480 

32 

32 

5065 

20.  260 

33 

33 

2742 

10.  968 

34 

34 

3707 

14. 828 

35 

35 

17652 

70. 608 

36 

35 

294 

1.  176 

37 

35 

297 

1.  188 

41 

41 

9966 

39. 864 

42 

42 

8317 

33. 268 

43 

43 

3268 

13. 072 

44 

44 

6738 

26. 952 

46 

46 

5991 

23.  964 

FGC/EIC 
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128290 


513.  158 


TABLE  FAILURES  TYPE  PAGE 


EQUIP  FAILURE  SUMMARY  BY  EQUIPMENT  TYPE  NUMBER 


TYPE 

TOTAL  EQUIP. 

AVG.  NO.  FAILURES 

MAINTENANCE 

STD.  DEV. 

FAILURES 

PER  MISSION 

HOURS 

MAINT.  HRS 

11 

2783 

11.  132 

2.  752 

0.  000 

12 

5586 

22. 344 

5.  544 

0.  000 

13 

4430 

17. 720 

4.448 

0.  000 

14 

2381 

9.  524 

2.  358 

0.  000 

15 

10792 

43. 168 

10. 816 

0.  000 

21 

17013 

68.  052 

16. 845 

0.  000 

23 

6985 

27. 940 

7.  002 

0.  000 

25 

4291 

17. 164 

4.  305 

0.  000 

26 

3122 

12.488 

3.  159 

0.  000 

31 

6870 

27.480 

6.  930 

0.  000 

32 

5065 

20. 260 

5.  057 

0.  000 

33 

2742 

10.  968 

2.  802 

0.  000 

34 

3707 

14. 828 

3.  762 

0.  000 

35 

18243 

72. 972 

18. 168 

0.  000 

41 

9966 

39. 864 

9.  877 

0.  000 

42 

8317 

33. 268 

8.  241 

0.  000 

43 

3268 

13. 072 

3.  344 

0.  000 

44 

6738 

26. 952 

6.  801 

0.  000 

46 

5991 

23. 964 

6.  148 

0.  000 

128290 

513.  158 

0.  019 

TABLE  SPARES  LEVEL  PAGE 


UNLIMITED  SPARES 
SUMMARY  OF  SPARES  USED 


FGC/EIC 
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ORGANIZATION 

SPARES 

INTERMEDIATE 

SPARES 

DEPOT  SPARES 

SPARE 

TOTAL 

USE  PER 

TOTAL 

USE  PER 

TOTAL 

USE  PER 

TYPE 

STOCK 

USED 

MISSION 

STOCK 

USED 

MISSION 

STOCK 

USED 

MISSION 

1 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

2 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

3 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

4 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

5 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

6 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

7 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

8 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

9 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

10 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  OOD 

11 

90000 

2783 

11.  132 

90000 

0 

0.  000 

90000 

0 

0.  000 

12 

90000 

5586 

22.  344 

90000 

0 

0.  000 

90000 

0 

0.  000 

13 

90000 

4430 

17. 720 

90000 

0 

0.000 

90000 

0 

0.  000 

14 

90000 

2381 

9.524 

90000 

0 

0.  000 

90000 

0 

0.  000 

15 

90000 

10792 

43. 168 

90000 

0 

0.  000 

90000 

0 

0.  000 

16 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

17 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

18 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

19 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

20 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

21 

90000 

17013 

68. 052 

90000 

0 

0.  000 

90000 

0 

0.  000 

22 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

23 

90000 

6985 

27. 940 

90000 

0 

0.  000 

90000 

0 

0.  000 

24 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

25 

90000 

4291 

17. 164 

90000 

0 

0.  000 

90000 

0 

0.  000 

26 

90000 

3122 

12.  488 

90000 

0 

0.  000 

90000 

0 

0.  000 

27 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

28 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

29 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 
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30 

90000 

0 

0.000 

90000 

0 

0.  000 

90000 

0 

0.  000 

31 

90000 

6870 

27.480 

90000 

0 

0.  000 

90000 

0 

0.  000 

32 

90000 

5065 

20. 260 

90000 

0 

0.  000 

90000 

0 

0.  000 

33 

90000 

2742 

10. 968 

90000 

0 

0.  000 

90000 

0 

0.  000 

34 

90000 

3707 

14. 828 

90000 

0 

0.  000 

90000 

0 

0.  000 

35 

90000 

18243 

72.  972 

90000 

0 

0.  000 

90000 

0 

0.  000 

36 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

37 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

38 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

39 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

40 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

41 

90000 

9966 

39. 864 

90000 

0 

0.  000 

90000 

0 

0.  000 

42 

90000 

8317 

33.  268 

90000 

0 

0.  000 

90000 

0 

0.  000 

43 

90000 

3268 

13. 072 

90000 

0 

0.  000 

90000 

0 

0.  000 

44 

90000 

6738 

26. 952 

90000 

0 

0.  000 

90000 

0 

0.  000 

45 

90000 

0 

0.  000 

90000 

0 

0.  000 

90000 

0 

0.  000 

46 

90000 

5991 

23.  964 

90000 

0 

0.  000 

90000 

0 

0.  000 

TABLE 

UNAVA  NUM 

PAGE 

RUN 

1/2:  NO 

STOCK  OF 

A-UNITS; 

ALLOWABLE 

DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  FULL  SYSTEM 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 


EQUIP  EQUIP 


NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

—  “ 

TYPE 

NO. 

FGC/EIC 

ASSEMBLY_A03 

52510. 1094 

0. 0138 

20.  81 

15 

15 

ELEMENT_C0101 

33285. 5586 

0. 0087 

13.  19 

31 

31 

SUBASSEMBLY_A01B 

27054. 7500 

0. 0071 

10.  72 

12 

12 

ELEMENT_C0102 

24513. 2500 

0. 0064 

9.  71 

32 

32 

SUBASSEMBLY.A02A 

21490. 1719 

0. 0056 

8.  51 

13 

13 

68 


ELEMENT_B0201 

20735. 0859 

0. 0054 

8.  22 

25 

25 

SUBASSEMBLY_C02B 

17946. 0820 

0. 0047 

7.  11 

34 

34 

SUBASSEMBLY_B02A 

15077. 8633 

0.  0040 

5.  97 

26 

26 

SUBASSEMBLY.AOIA 

13427. 8672 

0.  0035 

5.  32 

11 

11 

SUBASSEMBLY_C02A 

13275. 4180 

0. 0035 

5.  26 

33 

33 

ELEMENT_AO  201 

11482. 1250 

0.  0030 

4.  55 

14 

14 

ELEMENTS  0101 

620. 3950 

0.  0002 

0.  25 

21 

22 

ELEMENT_B0101 

522. 2812 

0.  0001 

0.  21 

21 

21 

ELEMENTJB0102 

209. 1828 

0.  0001 

0.  08 

23 

23 

ELEMENT_B0102 

108. 4651 

0. 0000 

0.  04 

23 

24 

SUBASSEMBLY_C03A 

4. 1523 

0.  0000 

0.  00 

35 

35 

SUBASSEMBLY_C03A 

4. 1523 

0. 0000 

0.  00 

35 

36 

SUBASSEMBLY_C03A 

4. 1523 

0.  0000 

0.  00 

35 

37 

TABLE  UNAVA  TYPE 

PAGE 

RUN  1/2:  NO  STOCK 

OF  A-UNITS; 

ALLOWABLE 

DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  FULL  SYSTEM 

UNAVAILABILITY  AND 


PERCENT 

OF  UNAVAILABILITY 

EQUIP 

NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

TYPE  FGC/EIC 

A.i£MBLY_A03 

52510. 1094 

0. 0138 

20.  81 

15 

ELEMENT.C0101 

33285. 5586 

0. 0087 

13.  19 

31 

SUBASSEMBLY_AO IB 

27054. 7500 

0. 0071 

10.  72 

12 

ELEMENT_C0102 

24513.  2500 

0. 0064 

9.  71 

32 

SU:..SSEMBLY_A02A 

21490. 1719 

0. 0056 

8.  51 

13 

ELEMENT J30201 

20735. 0859 

0. 0054 

8.  22 

25 

SUBASSEMBLY_C02B 

17946. 0820 

0. 0047 

7.  11 

34 

SUBASSEMBLY_B02A 

15077. 8633 

0. 0040 

5.  97 

26 

SUBASSEMBLY_AO 1A 

13427. 8672 

0. 0035 

5.  32 

11 

69 


SUBASSEMBLY_C02A 

13275.4180 

0.  0035 

5.  26 

33 

ELEMENT_A0201 

11482. 1250 

0. 0030 

4.55 

14 

ELEMENT_B0101 

1142. 6763 

0.  0003 

0.  45 

21 

EL£MENT_B0102 

317. 6477 

0.  0001 

0.  13 

23 

SUBASSEMBLY_C03A 

12.4570 

0.  0000 

0.  00 

35 

TABLE  UNREL  NUM 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  FULL  SYSTEM 

UNRELIABILITY  AND 


PERCENT  OF  MISSION  FAILURES 

DESCRIPTION 

NO. 

UNREL 

PERCENT 

EQUIP 

EQUIP  FGC/EIC 

FAILURES 

TYPE 

NO. 

ASSEMBLY_A03 

171.  0 

0. 6840 

68.  40 

15 

15 

ELEMENT_C0101 

22.  0 

0. 0880 

8.  80 

31 

31 

ELEMENT_C0102 

13.  0 

0. 0520 

5.  20 

32 

32 

SUBASSEMBLY_C02B 

10.  0 

0.  0400 

4.  00 

34 

34 

SUBASSEMBLY_A01B 

7.  0 

0. 0280 

2.  80 

12 

12 

SUBASSEMBLY.AOIA 

7.  0 

0. 0280 

2.  80 

11 

11 

E  LEMENT_B  0  201 

6.  0 

0. 0240 

2.  40 

25 

25 

ELEMENT_B0101 

4.  0 

0.  0160 

1.  60 

21 

21 

SUBASSEMBLY_A02A 

4.  0 

0. 0160 

1.  60 

13 

13 

ELEME.\T_B0101 

4.  0 

0. 0160 

1.  60 

21 

22 

SUBASSEMBLY_B02A 

2.  0 

0. 0080 

0.  80 

26 

26 

TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  FULL  SYSTEM  =  250 

TABLE  UNREL  TYPE  PAGE 
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RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  FULL  SYSTEM 

UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 

DESCRIPTION  NO.  UNREL  PERCENT  EQUIP  FGC/EIC 


FAILURES 

TYPE 

ASSEMBLY_A03 

171.  0 

0.  6840 

68.  40 

15 

ELEMENT_C0101 

22.  0 

0. 0880 

8.  80 

31 

ELEMENT_C0102 

13.  0 

0. 0520 

5.  20 

32 

SUBASSEMBLY_C02B 

10.  0 

0. 0400 

4.  00 

34 

ELEMENT_B0101 

8.  0 

0. 0320 

3.  20 

21 

SUBASSEMBLY_A01B 

7.  0 

0. 0280 

2.  80 

12 

SUBASSEMBLY_AO 1A 

7.  0 

0. 0280 

2.  80 

11 

ELEMENT_B0201 

6.  0 

0. 0240 

2.40 

25 

SUBASSEMBLY.A02A 

4.  0 

0. 0160 

1.  60 

13 

SUBASSEMBLY_B02A 

2.  0 

0. 0080 

0.  80 

26 

TOTAL 

NO. 

MISSION 

TRIALS  = 

250 

TOTAL 

NO. 

MISSION 

FAILURES 

FOR  FULL 

SYSTEM  =  250 

TABLE 

UNAVA  NUM 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEM_A 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 
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EQUIP 

EQUIP 

NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

TYPE 

NO.  FGC/EIC 

ASSEMBLY_A03 

53396.4375 

0.  0140 

41.  62 

15 

15 

SUBASSEMBLY_A01B 

27526. 8477 

0.  0072 

21.  46 

12 

12 

SUBASSEMBLY_A02A 

21859. 8164 

0.  0057 

17.  04 

13 

13 

SUB ASSEMBLY_AO 1A 

13680.  1523 

0.  0036 

10.  66 

11 

11 

ELEMENT_A0201 

11710. 7852 

0.  0031 

9.  13 

14 

14 

TABLE  UNAVA  TYPE 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS; 

ALLOWABLE 

DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEM_A 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 

EQUIP 


NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

TYPE  FGC/EIC 

ASSEMBLY_A03 

53396.4375 

0.  0140 

41.  62 

15 

SUBASSEMBLY.AOIB 

27526. 8477 

0.  0072 

21.  46 

12 

SUBASSEMBLY_A02A 

21859. 8164 

0.  0057 

17.  04 

13 

SUBASSEMBLY.AOIA 

13680.  1523 

0. 0036 

10.  66 

11 

ELEMENT.A0201 

11710.  7852 

0. 0031 

9.  13 

14 

TABLE  UNREL  NUM 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEM_A 

UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 
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DESCRIPTION 

NO. 

UNREL 

PERCENT 

EQUIP 

EQUIP  FGC/EIC 

FAILURES 

TYPE 

NO. 

ASSEMBLY_A03 

218.  0 

0. 8720 

87.  20 

15 

15 

SUBASSEMBLY_A01B 

16.  0 

0. 0640 

6.40 

12 

12 

SUBASSEMBLY_A01A 

9.  0 

0.  0360 

3.  60 

11 

11 

SUBASSEMBLY_A02A 

7.  0 

0.  0280 

2.  80 

13 

13 

TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBSYSTEM_A  =  250 

TABLE  UNREL  TYPE  PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEM_A 


UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 


DESCRIPTION  NO. 

FAILURES 

ASSEMBLY_A03  218. 0 

SUBASSEMBLY_A01B  16. 0 

SUBASSEMBLY_A01A  9.0 

SUBASSEMBLY_A02A  7.0 

TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBS 
TABLE  UNAVA  NUM 


UNREL 

PERCENT 

EQUIP  FGC/EIC 

TYPE 

0. 8720 

87.  20 

15 

0. 0640 

6.40 

12 

0. 0360 

3.  60 

11 

0.  0280 

2.  80 

13 

STEM.A  = 

PAGE 

250 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 
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CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEMS 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 


EQUIP 

EQUIP 

NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

TYPE 

NO.  FGC/EIC 

ELEMENTS  0201 

21394. 3789 

0.  0056 

55.  52 

25 

25 

SUBASSEMBLYS02A 

15552. 7617 

0.  0041 

40.  36 

26 

26 

ELEMENTS0101 

632. 1204 

0.  0002 

1.  64 

21 

22 

ELEMENTS0101 

533. 2466 

0.  0001 

1.  38 

21 

21 

ELEMENTS0102 

213. 4900 

0. 0001 

0.  55 

23 

23 

ELEMENTS0102 

112. 0133 

0. 0000 

0.  29 

23 

24 

TABLE  UNAVA  TYPE 

PAGE 

RUN  1/2:  NO  STOCK 

:  OF  A-UNITS; 

ALLOWABLE 

DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEMS 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 

EQUIP 


NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

—  - 

TYPE  FGC/EIC 

ELEMENT_B0201 

21394. 3789 

0. 0056 

55.  52 

25 

SUBASSEMBLYS02A 

15552. 7617 

0.  0041 

40.  36 

26 

ELEMENTS0101 

1165. 3669 

0. 0003 

3.02 

21 

ELEMENTS0102 

325.  5032 

0.  0001 

0.  84 

23 

TABLE  UNREL  NUM 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 
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CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEMS 

UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 


DESCRIPTION 

NO. 

UNREL 

PERCENT 

EQUIP 

EQUIP 

FAILURES 

TYPE 

NO. 

ELEMENTS0201 

164.  0 

0. 6560 

65.  60 

25 

25 

SUBASSEMBLYS02A 

67.  0 

0.  2680 

26.  80 

26 

26 

ELEMENTS0101 

9.  5 

0.  0380 

3.  80 

21 

22 

ELEMENTS0101 

7.  0 

0. 0280 

2.  80 

21 

21 

ELEMENTS  0102 

2.  5 

0. 0100 

1.  00 

23 

23 

FGC/EIC 


TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBSYSTEMS  =  250 

TABLE  UNREL  TYPE  PAGE 


RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 


CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEMS 


UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 


DESCRIPTION 

NO. 

FAILURES 

ELEMENTS  0  201 

164.  0 

SUBASSEMBLYS02A 

67.  0 

ELEMENTS0101 

16.  5 

ELEMENTS  01 02 

2.  5 

UNREL  PERCENT  EQUIP  FGC/EIC 


TYPE 

0. 6560 

65.  60 

25 

0. 2680 

26.  80 

26 

0.  0660 

6.  60 

21 

0. 0100 

1.  00 

23 
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TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBSYSTEMS  =  250 

TABLE  UNAVA  NUM  PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEMS 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 


EQUIP 

EQUIP 

NAME 

NUMBER  HRS 

UNAVA 

PERCENT 

TYPE 

NO.  FGC/EIC 

ELEMENTS0101 

34082. 2031 

0. 0090 

37.  35 

31 

31 

ELEMENTS0102 

25083. 2070 

0. 0066 

27.  49 

32 

32 

SUBASSEMBLYS02B 

18350.  3398 

0. 0048 

20.  11 

34 

34 

SUBASSEMBLYS02A 

13590. 7812 

0. 0036 

14.  89 

33 

33 

SUBASSEMBLYS03A 

4. 1523 

0. 0000 

0.  00 

35 

35 

SUBASSEMBLYS03A 

4. 1523 

0. 0000 

0.  OC 

35 

36 

SUBASSEMBLYS03A 

4.  1523 

0. 0000 

0.  00 

35 

37 

TABLE  UNAVA  TYPE 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 

CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEMS 

UNAVAILABILITY  AND 
PERCENT  OF  UNAVAILABILITY 


PERCENT 


EQUIP 

TYPE  FGC/EIC 


NAME 


NUMBER  HRS 
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UNAVA 


ELEMENTS0101 

34082.  2031 

0. 0090 

37.35 

31 

ELEMENTS0102 

25083. 2070 

0. 0066 

27.49 

32 

SUBASSEMBLYS02B 

18350. 3398 

0.  0048 

20.  11 

34 

SUBASSEMBLYS02A 

13590.  7812 

0.  0036 

14.  89 

33 

SUBASSEMBLYS03A 

12. 4570 

0.  0000 

0.  01 

35 

TABLE  UNREL  NUM 

PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 


CRITICAL  EQUIPMENT  BY  EQUIPMENT  NUMBER  FOR  SUBSYSTEMS 

UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 


DESCRIPTION 

NO. 

UNREL 

PERCENT 

EQUIP 

EQUIP 

FAILURES 

TYPE 

NO. 

E  LEMENTS  0101 

146.  0 

0. 5840 

58.40 

31 

31 

ELEMENTS0 102 

61.  0 

0. 2440 

24.40 

32 

32 

SUBASSEMBLYS02B 

39.  0 

0.  1560 

15.  60 

34 

34 

SUBASSEMBLYS02A 

4.  0 

0. 0160 

1.  60 

33 

33 

FGC/EIC 


TOTAL  NO.  MISSION  TRIALS  =  250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBSYSTEMS  =  250 

TABLE  UNREL  TYPE  PAGE 

RUN  1/2:  NO  STOCK  OF  A-UNITS;  ALLOWABLE  DOWNTIMES 


CRITICAL  EQUIPMENT  BY  EQUIPMENT  TYPE  FOR  SUBSYSTEMS 


UNRELIABILITY  AND 
PERCENT  OF  MISSION  FAILURES 
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DESCRIPTION 

NO. 

UNREL 

PERCENT 

EQUIP  FGC/FIC 

FAILURES 

TYPE 

ELEMENT_C0101 

146.  0 

0.  5840 

58.40 

31 

ELEMENT_C0102 

61.  0 

0. 2440 

24.  40 

32 

SUBASS£MBLY_C02B 

39.  0 

0.  1560 

15.  60 

34 

SUBASSEMBLY_C02A 

4.  0 

0.  0160 

1.  60 

33 

TOTAL  NO.  MISSION  TRIALS  = 

250 

TOTAL  NO.  MISSION  FAILURES  FOR  SUBSYSTEMS  =  250 

TABLE  REDM  PAGE 

RESTRICTED  ERLANG  DISTRIBUTION  MODEL 


MTBMF  =  299. 23 

2ND  MOMENT  ABOUT  ORIGIN  = 


97785. 12 


SHAPE  =11  Ml  = 


17.26  M2  =  28.20 


T  R-TIGER  R-THEO  DIFF  DIFSQ 


175.00  0.924  0.936  -.012  0.000 

AFB208I  VFNTH  :  PROGRAM  INTERRUPT  -  FLOATING-POINT  UNDERFLOW  EXCEPTION 

.  (SEEV.B.5.)  . 

STANDARD  CORRECTIVE  ACTION  TAKEN.  EXECUTION  CONTINUING. 

15230.  00  0.000  0.000  0.000  0.000 
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AVG  ABS  DIFF=0.  006 


MAX  ABS  DIFF=0.  012 


SQUARESSUM=0.  000 
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APPENDIX  C.  MODSIM-II-CODE  FOR  MODULE  GLOBAL 


This  appendix  contains  successfully  compiled  code  for  the  definition  of  those  vari¬ 
ables  and  types,  that  are  used  in  all  further  definition  and  implementation  modules.  The 
program  part  shown  is  the  DEFINITION  MODULE  "Global",  which  does  not  need  an 
accompanying  IMPLEMENTATION  MODULE,  because  no  procedure  or  method  has 
to  be  defined. 


DEFINITION  MODULE  Global; 

FROM  GrpMod  IMPORT  QueueObj; 
FROM  Debug  IMPORT  DebugStream; 


VAR 

{Fixed  parameters  according  to  Table  3) 

STotal 

:  INTEGER; 

SUnit 

:  INTEGER; 

UD 

:  INTEGER; 

DC 

:  INTEGER; 

uc 

:  INTEGER; 

MartA 

:  REAL; 

MartB 

:  REAL; 

LDTstock 

:  REAL; 

LDTDES 

:  REAL; 

LDTsupply 

:  REAL; 

ADT2 

:  REAL; 

ADT3 

:  REAL; 
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{Variable  parameters  according  to  Table  4;  stock  levels  handled  by 
StockObject] 

R2  :  INTEGER; 

R3D  :  INTEGER; 

R3C  :  INTEGER; 

{Variable  requirement  parameter  according  to  Table  5  handled  by 
ComponentOb j ect } 

TYPE 

IndentLevelType  =  (System,  Aunit,  Bunit ,  Cunit,  Dunit); 

StatusType  =  (operating,  pausing,  broken,  standby); 

MaintLevelType  =  (Organizational,  Intermediate); 

QualType  =  (Electronic,  Optronic,  Communication, 

WeaponGuidance ,  RADAR,  LASER,  Electrical, 
Mechanical); 

ComponentTypeQueue  =  QueueObj; 

BrokenPartsTypeQueue  =  QueueObj; 

IdleRepairTypeQueue  =  QueueObj; 

WaitingJobTypeQueue  =  QueueObj; 

StockTypeQueue  =  QueueObj; 

END  MODULE. 
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APPENDIX  D.  MODSIM-II-CODE  FOR  MODULE  WEAPONSYSTEM 


This  appendix  contains  successfully  compiled  code  for  the  three  objects  necessary 
to  model  the  behavior  of  a  four-indenture-level  electronic  weapon  system: 

1.  Component-Object 

2.  Element-Object 

3.  WeaponSystem-Object 

The  first  program  part  shown  is  the  DEFINITION  MODULE,  followed  by  the  accom¬ 
panying  IMPLEMENTATION  MODULE. 


DEFINITION  MODULE  WeaponSystem; 

FROM  SimMod  IMPORT  SimTime; 

FROM  RandMod  IMPORT  RandomObj; 

FROM  GrpMod  IMPORT  QueueObj; 

FROM  Maintenance  IMPORT  OrgMaintObj; 

FROM  Global  IMPORT  ALL  StatusType,  ComponentTypeQueue , 

ALL  IndentLevelType,ALL  QualType, 
BrokenPartsTypeQueue; 


EXPORTTYPE 

CompObj  =  OBJECT;  FORWARD; 


WeaponSystemObj  = 

TYPE 

CompObj  =  OBJECT 

Name 

IndentLevel 

Technology 

MasterComponent 


OBJECT;  FORWARD; 


STRING; 

IndentLeve lType; 

QualType; 

CompObj; 
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Tenants  :  ComponentTypeQueue; 

Status  :  StatusType; 

BrokenParts  :  BrokenPartsTypeQueue; 

StandByAvail  :  BOOLEAN; 

ASK  METHOD  Break  (IN  BrokenParts  :  BrokenPartsTypeQueue); 
{CompObj  is  informed  about  an  occurred  failure  within  its 
ComponentTypeQueue,  and  passes  message  and  the  names  of  the 
broken  components  at  each  respective  IndentLevel  upwards  to 
its  MasterComponent ) 

ASK  METHOD  Pause; 

{CompObj  is  informed  about  an  occurred  failure  within  its 
WeaponSystemObj ,  and  is  told  to  pause  in  its  aging  process 
until  WeaponSystemObj  is  up  again} 

ASK  METHOD  UpAgain; 

{CompObj  is  told  to  change  to  Status=operational } 

END  OBJECT; 

ElementObj  =  OBJECT( CompObj ) 

mean  :  REAL; 

alpha  :  REAL; 

{Gamma  distribution  for  time  between  failures} 

TimeToFailure  :  REAL; 

Discard  :  BOOLEAN; 

TELL  METHOD  ComputeNextFail; 

{ElementObj  is  told  to  calculate  its  next  time  to  failure} 
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ASK  METHOD  Fail; 

{ElementObj  is  asked  to  fail,  and  passes  message  and  its  own 
name  upwards  to  its  MasterComponent] 

END  OBJECT; 

WeaponSystemObj  =  OBJECT(CompObj) 

StartDownTime  :  REAL; 

SumOfDownTimes  :  REAL; 

AverageAvailability  :  REAL; 

MilitaryUnit  :  OrgMaintubj; 

ASK  METHOD  DownTime  (OUT  AverageAvailability  :  REAL); 
(WeaponSystemObj  is  asked  to  report  SumOfDownTime } 

OVERRIDE 

ASK  METHOD  Break  (IN  BrokenParts  :  BrokenPartsTypeQueue); 

(WeaponSystemObj  is  informed  about  an  occurred  failure  within 
its  ComponentTypeQueue ,  and  orders  its  entire 
ComponentTypeQueue  to  pause] 

END  OBJECT; 

END  MODULE. 


IMPLEMENTATION  MODULE  WeaponSystem; 

FROM  SimMod  IMPORT  SimTime; 

FROM  RandMod  IMPORT  RandomObj; 

FROM  GrpMod  IMPORT  QueueObj; 
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FROM  Maintenance  IMPORT  OrgMaintOb j ,  IntMaintObj; 

FROM  Global  IMPORT  ALL  IndentLevelType,  ALL  StatusType,  ALL  QualType, 

ComponentTypeQueue , B  rokenPartsTypeQueue; 


VAR 

RandomGenerator  :  RandomObj; 
i  :  INTEGER; 


OBJECT  CompObj; 

ASK  METHOD  Break  (IN  BrokenParts  :  BrokenPartsTypeQueue); 

BEGIN 

Status  :  =  broken; 

ASK  BrokenParts  TO  Add  (SELF); 

IF  IndentLevel  <>  System 

ASK  MasterComponent  TO  Break  (BrokenParts); 

END  IF; 

END  METHOD; 

ASK  METHOD  Pause; 

BEGIN 

Status  :=  pausing; 

Tenants  :=  ASK  Tenants  First(); 

FOR  i:=l  TO  ASK  Tenants  numberln 
Status  :=  pausing; 

Tenants  :=  ASK  Tenants  Next  (SELF); 

END  FOR; 

END  METHOD; 

ASK  METHOD  UpAgain; 

BEGIN 

Status  :  =  operating; 
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END  METHOD; 


END  OBJECT; 

OBJECT  ElementObj; 

TELL  METHOD  ComputeNextFail; 

BEGIN 

TimeToFailure  :=  ASK  RandomGenerator  Gamma  (mean, alpha); 
WAIT  DURATION  TimeToFailure 
END  WAIT; 

ASK  SELF  TO  Fail; 

END  METHOD; 

ASK  METHOD  Fail; 

BEGIN 

Status  :  =  broken; 

ASK  BrokenParts  TO  Add  (SELF); 

ASK  MasterComponent  TO  Break  (BrokenParts); 

END  METHOD; 

END  OBJECT; 

OBJECT  WeaponSystemObj; 

ASK  METHOD  Break  (IN  BrokenParts  :  BrokenPartsTypeQueue); 

BEGIN 

Status  : =  broken; 

StartDownTime  :=  SimTime(); 

Tenants  :=  ASK  Tenants  FirstQ; 

FOR  i:  =1  TO  ASK  Tenants  numberln 
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Status  :=  pausing; 

Tenants  :=  ASK  Tenants  Next  (SELF); 

END  FOR; 

ASK  MilitaryUnit  TO  OrgQueueJob  (SELF); 

END  METHOD; 

ASK  METHOD  DownTime  (OUT  AverageAvailability  :  REAL); 

BEGIN 

AverageAvailability  :=  (SimTimeQ  -  SumOfDownTimes)/  SimTime(); 
END  METHOD; 

END  OBJECT; 

END  MODULE. 
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APPENDIX  E.  MODSIM-II-CODE  FOR  MODULE  MAINTENANCE 


This  appendix  contains  successfully  compiled  code  for  the  two  objects  necessary  to 
model  the  behavior  of  the  two  studied  major  Maintenance-Echelon- Levels  in  the 
Three-Level- Maintenance-System  of  the  German  Army: 

1 .  Organizational-Maintenance-Object 

2.  Intermediate-Maintenance-Object 

The  first  program  part  shown  is  the  DEFINITION  MODULE,  followed  by  the  accom¬ 
panying  IMPLEMENTATION  MODULE. 


DEFINITION  MODULE  Maintenance; 


FROM  VeaponSystem  IMPORT  CompOb j ,  WeaponSystemObj ; 

FROM  GrpMod  IMPORT  QueueObj; 

FROM  Global  IMPORT  ADT2 , ADT3 , LDTstock , LDTDES , LDTsupply , 

ALL  IndentLeve lType , BrokenPartsTypeQueue , 
IdleRepairTypeQueue ,  WaitingJobTypeQueue , 
StockTypeQueue; 

FROM  Repair  IMPORT  RepairObj; 

EXPORTTYPE 

OrgMaintObj  =  OBJECT;  FORWARD; 

IntMaintObj  =  OBJECT;  FORWARD; 


TYPE 

OrgMaintObj  =  OBJECT 


Name 

NumberRepairObj 

IdleRepairFacilities 

IdleFacility 


STRING; 

INTEGER; 

IdleRepai rTyp eQueue ; 
RepairObj; 
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Stock  :  StockTypeQueue; 

JobQueue  :  WaitingJobTypeQueue; 

ComponentToReplace  :  CompObj; 

ResponsiblelntMaintFac:  IntMaintObj; 

j  :  INTEGER; 

r  :  INTEGER; 

ASK  METHOD  OrgQueueJob  (IN  WeaponSystem  :  WeaponSysteraObj ); 

[OrgMaintObj  is  told  to  receive  a  WeaponSystemObj  and  to  queue 
its  broken  Subsystem  into  its  JobQueue} 

ASK  METHOD  ReportOfldle  (IN  RepairFacility  :  RepairObj); 

[MaintObj  is  told  to  receive  a  RepairObj  and  either  to  assign 
it  a  job  or  to  queue  it  into  its  IdleRepairQueue} 

TELL  METHOD  Assign  (IN  RepairFacility  :  RepairObj; 

IN  ComponentToReplace  :  CompObj); 

[MaintObj  is  asked  to  assign  a  CompObj  to  the  asking  RepairObj; 
both  the  admistrative  delay  time  ADT2  and  the  respective 
logistic  delay  time  LDTstock  /  LDTDES  /  LDTsupply  are 
considered  within  this  method] 

ASK  METHOD  SendToRepair  (IN  Component  :  CompObj); 

[MaintObj  is  asked  by  the  telling  RepairObj  that  a  replaced 
Com  pObj  has  to  be  sent  to  the  ResponsiblelntMaintFac} 

END  OBJECT; 

IntMaintObj  =  OBJECT( OrgMaintObj ) 

ASK  METHOD  IntQueueJob  (IN  Component  :  CompObj); 

[IntMaintObj  is  told  to  receive  a  CompObj  and  to  queue  it  into  its 
JobQueue;  if  queued  CompObj  is  first  in  JobQueue,  initiate  its 
assignment  to  the  first  RepairObj  of  IdleRepairObjQueue} 
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OVERRIDE 

TELL  METHOD  Assign  (IN  RepairFacility  :  RepairObj; 

IN  ComponentToReplace  :  CompObj); 

{MaintObj  is  asked  to  assign  a  CompObj  to  the  asking  RepairObj; 
both  the  admistrative  delay  time  ADT3  and  the  respective  logistic 
delay  time  LDTstock  /  LDTsupply  are  considered  within  this  method} 

END  OBJECT; 

END  MODULE. 


IMPLEMENTATION  MODULE  Maintenance; 

FROM  WeaponSystem  IMPORT  CompObj,  VeaponSystemObj ; 

FROM  GrpMod  IMPORT  QueueObj; 

FROM  Global  IMPORT  ADT2.ADT3, LDTstock, LDTDES, LDTsupply, 

ALL  IndentLevelType , BrokenPartsTypeQueue , 
IdleRepairTypeQueue,  WaitingJobTypeQueue , 
StockTypeQueue; 

FROM  Repair  IMPORT  RepairObj; 

OBJECT  OrgMaintObj; 

ASK  METHOD  OrgQueueJob  (IN  WeaponSystem  :  WeaponSystemObj); 

BEGIN 

ComponentToReplace  :=  ASK  WeaponSystem.  BrokenParts  Last(); 
r  :=  ASK  IdleRepairFacilities  numberln; 

IF  r=0 

ASK  JobQueue  TO  Add  (ComponentToReplace); 

ELSE 
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IdleFacility  :=  ASK  IdleRepairFacilitiesRemove( ); 

TELL  SELF  TO  Assign  (IdleFacility,  ComponentToRepl ace); 
END  IF; 

END  METHOD; 

ASK  METHOD  ReportOfldle  (IN  RepairFacility  :  RepairObj); 

BEGIN 

j  :  =  ASK  JobQueue  numberln; 

IF  j=0 

ASK  IdleRepairFacilities  Add  (RepairFacility); 

ELSE 

ComponentToRepl  ace  :=  ASK  JobQueue  RemoveQ; 

TELL  SELF  TO  Assign  (RepairFacility,  ComponentToReplace) 
END  IF; 

END  METHOD; 

TELL  METHOD  Assign  (IN  RepairFacility  :  RepairObj; 

IN  ComponentToReplace  :  CompObj); 

BEGIN 

TELL  RepairFacility  TO  Fix  (ComponentToReplace); 

END  METHOD; 

ASK  METHOD  SendToRepair  (IN  Component  :  CompObj); 

BEGIN 

ASK  ResponsiblelntMaintFac  TO  IntQueueJob  (Component); 

END  METHOD; 

END  OBJECT; 

OBJECT  IntMaintObj; 

ASK  METHOD  IntQueueJob  (IN  Component  :  CompObj); 
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BEGIN 

ComponentToReplace  :=  ASK  Component.  BrokenParts  Last(); 
r  :=  ASK  IdIeRepairFaciliti.es  numberln; 

IF  r=0 

ASK  JobQueue  TO  Add  (ComponentToReplace); 

ELSE 

IdleFacility  :=  ASK  IdleRepairFacilities  RemoveO; 

TELL  SELF  TO  Assign  (IdleFacility,  ComponentToReplace); 
END  IF; 

END  METHOD; 

TELL  METHOD  Assign  (IN  RepairFacility  :  RepairObj; 

IN  ComponentToReplace  :  CompObj); 

BEGIN 

TELL  RepairFacility  TO  Fix  (ComponentToReplace); 

END  METHOD; 

END  OBJECT; 

END  MODULE. 
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